Attack of the Alien Space Beetles!
Community Forums/Showcase/Attack of the Alien Space Beetles!
| ||
| Since I'm running low on cash, and the art for Ice Cream Showdown is at least another three to six months from completion, I recently started work on a shooter. Why a shooter? Because it is easy to code, fun, and I have pretty much all the graphics and sounds I need for it at hand. The only thing I will need to do is hire a musician to write some XM tunes when the game is near completion. It's coming along pretty nicely so far. The sprites were low res originally but I used a Photoshop trick I invented that produces results similar to those of Gameboy emulators to increase the resolution by 3x. (Scale by 300% using nearest neighbor filtering and apply a 1 pixel median filter.) Since I'm working with what I have available for graphics, the game will be a bit wacky. The powerups include things like watermelon, a turkey leg, a sneaker with wings, and an umbrella. As you will see, each enemy will have its own specific attack patterns, and issues a "battle cry" when it appears on the screen. The demo has three enemis, though only two have a battle cry at this time. Many of the enemies will fire bullets off at random to create a little more chaos than there is right now. The control is with the mouse to make it more accessable to the casual gamer, but I think you'll find even with the mouse, when an enemy is moving in a sine wave it's kinda hard to hit, and you will have bullets and more enemies to worry about in the final version. Another interesting thing about the demo is the scrolling star background. I found that even at high framerates, you get a "strobing" effect on fast moving objects. This is a condition where you see an object in two locations at the same time, and flickering. Apparently this is an optical illusion caused by your eyes when an object does not overlap from one frame to the next as it moves. So your framerate dictates how fast objects can move, and if they move faster than their width allows and you don't have motion blur, then you get this strobing effect. So that's exactly what I did... Implement a cheap sort of motion blur. I basically just render a line from where a star was in the last frame, to where it is in the current frame. Thus stars that move faster get stretched out more, and if the framerate is lower, the game compensates with more of this fake motion blur. The results are pretty impressive, as the scrolling is much smoother this way than how it was without the stretching. Anyway, here's the demo. It's fairly basic. There is a tile screen which you press any key or the mouse button to skip, and in the game you move the mouse and press the mouse button repeatedly to fire. The game does not yet spawn enemies automatically, so you will need to press the buttons 1-4 to activate the various attack patterns. If you want to see the other enemies and bosses, and the powerups, and hear the various sound effects that will be in the game, they are included in the zip. http://www.seamlesstexturegenerator.com/asb/asb.zip |
| ||
| The sprites were low res originally but I used a Photoshop trick I invented that produces results similar to those of Gameboy emulators to increase the resolution by 3x. (Scale by 300% using nearest neighbor filtering and apply a 1 pixel median filter.) You could have used the original stuff : http://www.hiend3d.com/hq2x.html |
| ||
| I knew about that, but I decided not to use it because the results I got with my method were better. That Hq method blends colors when they are similar. This looks okay in some cases, but because it has a hard cutoff point rather than smoothly transitioning between blending and not blending, you get these sharp transitions in the middle of some gradients. It looks better and more retro to just have the gradients all be stepped than to have these blurry portions mixed with these sharp transitions. I also tried another util which was made by the author of one of those graphics enhancers, and that too did not produce satisfactory results. Of course, the results I get with my own method are not perfect either, but I thought they looked better than the other methods. I think I could write a function to do a better job than the ones I found and this photoshop method, but I really don't have the time to waste on that. You can't even really see the detail when the enemies are moving about anyway. But the main problem with these setups is detecting the curvature of edges. If you have a shape like this: # # # # Then that needs to be translated into a circle, but my median methods and the other methods turn something like that into more of an octagon or diamond shape. I think maybe you need to do something similar to metablobs to get the best shape. |
| ||
| isn't there a photoshop filter for this? |
| ||
| The median filter I used is about as close as you'll get. No filter is going to scale the image up for you, so you have to take that step anyway. |
| ||
| Sswift: A completly different question :) Where did you get the SFX ? |
| ||
| The movement/scrolling is pretty jerky on my PC. Everything 'stutters' along, when in motion. As for the game itself, it's obviously only an early WIP but it reminds me a bit of Galaga88. That was a great shooter because it was that bit different. I loved the dancing alien bonus screens. |
| ||
| Big10p: Could you press TAB in the demo and tell me what the framerate counter says? Also, tell me your system specs, and if you generally have issues running in 800x600. The game picks the same bitdepth as your desktop. AlienForce: Most of the sound effects came from "Sound Pool DVD 2004" by Magix. The 2005 edition is out now though and I don't know if the sounds are different or not. The DVD is mostly music loops in various genres, but it has a generous sound effects collection as well. |
| ||
| The FPS changes very fast so I can't really see too well, but it seems to constantly change between ~29 to ~35. I haven't had problems with 800x600 in the past - it's the mode I use myself most commonly. My desktop bitdepth is 32-bit. Specs: Athlon 1Ghz, GeForce2 GTS 32MB, 256MB RAM, Win98SE |
| ||
| I get a constant 58 FPS ... very retro looking. Specs : P4 3ghz , Geforce 440mx 64MB , 1gb ram , WinXPPro. |
| ||
| Big10, have you by chance set your card to force vwait on? You can do that on the display control panel for most cards these days. The framerate you are getting suggests to me that you are, because it is about the framerate I was getting when I was making the game wait for vwait. Try pressing F to switch to windowed mode. I don't think vwait is ever enabled when you are running a game in windowed mode, even if you try to turn it on in Blitz or on the control panel. Tell me what the framerate says there. The framerate is supposed to change fast btw. :-) |
| ||
| Aa-ttack!....of the killer tomatoes!!!! Aa-ttack!....of the killer tomatoes!!!! |
| ||
| 58FPS too. Keep working on it. When you press escape from the game and the main logo fades in the stars are obscured temporarily, no alphablend I guess. regarding the stars, my Iron Fist has a horiz scrolling star field and the stars move more than one pixel per frame. If you foollw a star with your eye, it's perfectly smooth. If you look at a fixed point on the screen (the logo for example) it looks like each star actually has 3-4 stars very close together, even though they absolutely do NOT exist at the same time on the same frame, weird. I can't see any "strobing" effect though. I have seen games where the frame rate drops below Vertical Refresh and this often makes it look like there are 2 stars, maybe this is what you were seeing? Sswift: checkout Jewel or Orion in my sig. It's totally unfinished but more playable than yours ;-) The star background was made with STG Pro. Keys are arrows and Z to fire. Includes my own cheezy XMs. Try pressing 1-9 for more bullets. D shows debug info, and on mine it's running at 85fps (refresh rate of my desktop). Funny thing is it's 800x600 too so how come yours is running at 58fps? If it's running at 58fps yet the refresh is 85Hz then this *may* explain the 2 star strobey thing. |
| ||
| Grey: Yeah, I know the title obscures the stars. It's hardly noiceable though and it would be far slower to do alpha. Alpha requires a readpixel from the screen buffer or blitting a fullscreen image from offscreen, while rendering something after multiplying it with a specific color does not. "I can't see any "strobing" effect though." Seeing 3-4 copies of the star is precisely the "strobing" effect I was talking about. That's what they call it in TV broadcasting according to some website I read. Although seeing 3-4 sounds a bit crazy. I saw two. "Funny thing is it's 800x600 too so how come yours is running at 58fps? If it's running at 58fps yet the refresh is 85Hz then this *may* explain the 2 star strobey thing." I can probably get the fps up from where it is right now. I'm gonna play around with some stuff. I just wrote a new FPS calculator to do averaging and show the average difference between the average fps and the instant fps, so you can see how much the framerate actually varies one way or the other. So now I can see how changes affect things more accurately. Part of the reason it might not run so fast is because each pixel of the stars that are plotted is checked against the prexisting pixels to see if the prexisting pixel is brighter. I do this because it would look wrong if a darker slower moving star passed over a brighter star. However, I don't really need to do that. I only did it because it was simplest to code at the time. I really ought to just insert the stars at the correct position in the type each time I create a new one so they are sorted from back to front. Then I can get rid of those readpixels. I guess I will do that now. |
| ||
| Okay try the latest version guys. Link is the same as above. This version will give you around 500 fps in windowed mode (no vwait) and whatever your screen refresh is in fullscreen mode. Press F to toggle between the two. I tried erasing the stars by drawing over them, and I sorted the stars as well to get rid of the readpixels, but it turned out that this was not the real bottleneck. I only got perhaps 3fps more using that method than by simply clearing the buffer each frame. It turns out that what I really needed to do was use image flag 2 on the star backdrop image. See, I haven't been drawing the stars to the screen itself. I have been drawing them to an image which I could then blit to the screen with my BOB system. This was probably a bad idea, but I did it because I thought it would be faster for some reason I no longer remember. I think I thought it would be faster to erase individual stars from an image in video memory and then draw individual stars to said image than it would be to clear the screen. Anyway, flags 1 and 3 keep a copy of the image in main memory so it won't get corrupted when you switch from windowed to fullscreen mode and back. 2 does not do this. So I have to clear the star image each frame to account for that. But even with that, because flag 2 keeps the image only in video memory it's not copying all the image data over the agp every frame, so it is much faster. I guess the card can clear the image on the card which is fast, rather than sending the data to clear the image over the agp. I might now try simply clearing the screen and blitting the stars to the screen which is what I should have done in the first place, being the most obvious and simplest solution. |
| ||
| Okay, the current version now simply draws the stars on the screen, which is by far the fastest. I have enabled checking for vertical refresh and enabled the framerate clamp to clamp the max framerate the game can run at at 100. This keeps the game from hogging all the CPU resources and also keeps the mouse movement smooth. If the game is allowed to run at 500fps then the ship will move really fast when the mouse is moved because it is simply checking and updating the movement so often it is not calculating the mouse speed accurately. However, in the interest of people being able to check their true framerate I have added a hotkey, V, which toggles both the framerate clamp and vwait check off. If you press this then when you hit tab you'll see just how fast this baby would run now if I didn't have those safties in place. Big10p, lemme know if the game runs smooth now, with or without the clamping on. |
| ||
| I just added the following: 1. The ship will now explode when it touches an enemy, and the enemy will explode with it. 2. Whenever the ship respawns, it flies up from the bottom of the screen. During this period the player cannot control the ship or fire, but the ship is invincible during this period and for a short while after to allow the player to get out of the way of incoming enemies. The ship blinks to inform the player that it is invincible during this time. |
| ||
| Part of the reason it might not run so fast is because each pixel of the stars that are plotted is checked against the prexisting pixels to see if the prexisting pixel is brighter. I do this because it would look wrong if a darker slower moving star passed over a brighter star. However, I don't really need to do that. I only did it because it was simplest to code at the time. I really ought to just insert the stars at the correct position in the type each time I create a new one so they are sorted from back to front. Then I can get rid of those readpixels. I guess I will do that now. this was quite funny, a sorta train of thought that led to your own solution :-)As it ran at 58fps on mine and someone elses, I thought this was very close to 60fps and wondered if you were using some kind of timer originally? I know you've changed it all now. OK now it runs at 85fps. btw, I assume your stars don't have integer coords, and that the coords are floats? How are you rounding them when they are plotted on-screen? They seem a tiny bit jerky to me and this suggests you are letting blitz do the rounding and it will be doing "bankers" rounding resulting in uneven distribution of the rounding esp. for .5 values. Try this around each coord: Floor(coord#+0.5) It really makes a difference, trust me. Also I know you tried to elimate the "stobing" effect, but you've just ended up with thes elongated stars (at least on my screen). If I stare at a fixed point they become even longer because the strobing effect is still in operation, you've just removed the gap between each "copy". But if I read your fist post correctly, this is what you intended to do anyway. |
| ||
| As it ran at 58fps on mine and someone elses, I thought this was very close to 60fps and wondered if you were using some kind of timer originally? I know you've changed it all now. Yeah, it did, and still does have a MAX_FPS thing which delays the current frame if it takes less than X milliseconds to render. This keeps it from exceeding MAX_FPS, which was set to 60, and is now set to 100, unless you press V to turn it off. If you press V it will run as fast as it can, but the mouse movement will be messed up because one pixel of mouse movement at 500fps translates to an assumption that the mouse is moving really fast. I suppose there must be some way to correct for that, but it's not really an issue when I limit the FPS to 100. btw, I assume your stars don't have integer coords, and that the coords are floats? How are you rounding them when they are plotted on-screen? They seem a tiny bit jerky to me and this suggests you are letting blitz do the rounding and it will be doing "bankers" rounding resulting in uneven distribution of the rounding esp. for .5 values. Try this around each coord: Floor(coord#+0.5) It really makes a difference, trust me. Do you take me for an amateur? :-) Harumph! ; Draw the stars. ; Make sure darker stars are not drawn over brighter stars. For ThisStar = Each Star Y1 = Floor(ThisStar\OldY#) Y2 = Floor(ThisStar\Y#) ; Clamp lines to screen border. If Y1 < 0 Then Y1 = 0 If Y2 > 599 Then Y2 = 599 ; Draw line if in screen. If (Y2 >= 0) And (Y1 <= 599) For Y = Y1 To Y2 WritePixelFast Floor(ThisStar\X#), Y, ThisStar\RGB, DestBuffer Next EndIf Next See? FLOOR! That bankers rounding in Blitz though really drives me nuts. I hate it. It also drives me nuts that there is no DIV command. Half the time I'm trying to do integer math or float to integer math I'm not 100% sure of what the heck Blitz is gonna do so I have to stick float() where I might not actually need to or do dumb stuff like subtract the mod of some value minus anothe value from that value minus that value again just to get a div. It's painful. I don't know what Mark was thinking when he decided to do banker's rounding. Also I know you tried to elimate the "stobing" effect, but you've just ended up with thes elongated stars (at least on my screen). If I stare at a fixed point they become even longer because the strobing effect is still in operation, you've just removed the gap between each "copy". But if I read your fist post correctly, this is what you intended to do anyway. Well I think it looks a lot better this way than it does without anything. I suppose one could make the stars stretch over the positions from TWO frames in the past, rather than one. That would make the lines only move half a width each frame, whereas right now, they only overlap by a single pixel. Or, perhaps the problem is that one pixel of overlap. I can eliminate that by simply adding one to the start location. I'll try that and see if that fixes the problem. |
| ||
| Just updated again. I tried rendering the stars stretched over the last two frames, but that just seemed to make the problem worse, not better. Drawing the startpoint one pixel below the last end point seemed to help some, and makes sense... If you have a star moving four pixels a frame, why would you want the star to stretch over five pixels? I also added a second attack pattern for the "scaredy ghost" enemy, so it can now emerge from the left or right. |
| ||
| So you are using floor but NOT adding 0.5 to the coordinate. This (as I'm sure you know) means a value of 3.8 goes to 3 instead of 4. Why do you want that kind of rounding?. Adding 0.5 to it gets rid off the effect of bankers rounding but still rounds perfectly (i.e. 0.5s always go up instead of up then down then up then down etc. |
| ||
| I have vsync set to application controlled but my GFX driver is less than stable and sometimes crashes when I play with the settings, so it could be doing anything, TBH. Changing to windowed mode made no difference with the original exe. The latest exe is much smoother but still not totally smooth - still get occasional jerking. In fullscreen, the FPS still flicks around very fast (it goes above 100 sometimes), but I get an FPS AVG of a pretty constant 60. In windowed mode, the FPS increases to an average of around 108. BTW, my monitor is a strange beast and only does 60Hz in every mode. |
| ||
| Reminds me of the "eagle" rendering used by some emulators... |
   |