Speed Run - a BMax vertical scrolling demo
Community Forums/Showcase/Speed Run - a BMax vertical scrolling demo
| ||
| Hiya, just thought I'd make some more demo code to show off the framework. Lots of people wanted to see scrolling so here is a vertically scrolling (with variable speed) demo-game: [edit] There are two versions. One rounds to the nearest pixel (but seems a tiny bit juddery as a result) and one uses floating point coords for the tiles (smoother) but has an anti-aliasing flicker on the edge of some tiles. See which you prefer: (integer) http://www.greyaliengames.com/downloadtrack.php?id=8 (2.2Mb zip file) (floating point) http://www.greyaliengames.com/downloadtrack.php?id=9 (2.2Mb zip file)  Basically just move round with the arrow keys and collect the green arrows to go faster and the red arrows to slow down - that's it. It *may* turn into a more complete game one day... (This is actually based on a game I prototyped on my Amiga 1200 in Blitz Basic 2, *before* Wipeout and the Playstation existed. It was a lot harder to get the scrolling perfect on the Amiga but it was lush and smooth.) I'll be releasing this source code with V1.03 of my BlitzMax Game Framework. It took 4 hours (including 1.5 hours for making graphics, sounds and plugging in some of my music) - so not long. If you want to find out more about the framework, please go here: http://www.greyaliengames.com/framework/faq.html |
| ||
| It was a lot harder to get the scrolling perfect on the Amiga Ahhh, but thats why you always did it first, and based your game model on how you did it. Nowadays just go "What the hell, Ill redraw it all" |
| ||
| yep, I just draw it all now. Back then it was a case of having an area of memory twice as tall as the screen and moving the visible window and only drawing the "new" area of the screen twice - once on-screen and once on the off-screen "mirror" of the main screen so when you hit the top edge of the big window it could flip back to the bottom "mirror" screen. I was pretty pleased when I figured that out. Then I made it work in 4 directions (well any) for a platformer. My next demo may be a platformer...or, um, a card game... |
| ||
| I normaly used to have a border round the screen that was the size of the maximum scroll. Then if you scrolled to the right (say), I would Blitz the screen left, and draw the new vertial bar into the border on the right. Mindyou all my stuff was strat, and I suppose all yours was flash and bang. |
| ||
| Yeah I see, your method meant an entire screen blit every say 32 pixels (border width) then. I saw a few games do this but they often jerked with the load every 32 pixels or whatever. My method only ever drew two thin strips so there was never a jerk :-) |
| ||
| Ahh, but in strat games you would normaly simply make the scroll min 32 pixels (or whatever), so that the jerk happened every frame, and was then not noticable. The selection of which to use would basicly come down to how much stuff you then had to figure out went on top of the basic map. Or how different two screen up was supposed to look to here In a flash and bang, you have a couple of explosions, the player and (say), some pickups. In a strat you may have twenty tanks/swords on one square, so the time you saved in calulating what you should draw on each squre was worth it. (well ok, not worth it, but no one expected NWN2 or BAttlefield 2140) Edit: Your demo is smooth |
| ||
| On my system there is a jerk in the scrolling about every couple seconds. When I switched to DX and then back to GL, blue screen and reboot. After I was back up I tried again and enabled debug mode display. Closed the demo by hitting the exit button from the main menu and blue screen/reboot again. |
| ||
| Scrolling on the Amiga was actually quite easy; vertical scrolling was a piece of piss, just change some registers in the copper list. |
| ||
| H&K. Ah I get it, sorry I didn't really take in "Strategy" before, yeah it makes sense and mine were "flash bang" yep. Glad it was smooth. just change some registers in the copper list. Uh, but that wouldn't let you show a continually scrolling background for ever without some extra work doing some drawing in the right place. Yeah the copper change was just to repoint the visible screem in RAM to a new location.TeaVirus: That's disappointing, I wonder why...So you got a blue screen on exit! Well it's not doing anything special in the exit code. Flips from DX to OpenGL fine on mine. You ever try any of my other games and have problems? I recall from testing a long time ago that some PCs to get jerks even though they are adequate to run it. You probably don't won't to run it again due to the crashes, but try this to see if it makes it smoother: FULL SCREEN PROCESS PRIORITY, FULL SCREEN THREAD PRIORITY, WINDOWED PROCESS PRIORITY, and WINDOWED THREAD PRIORITY control the game priority in Windows. By default these values are set to 0 (normal) but you can boost them to 1 or 2 if you want. A good setting is 1 on all flags; this will help if other windows programs are hogging too much CPU time. However, a value of 1 for the PROCESS flags is not supported in Windows 95/98/ME; nothing will happen. Also a value of 2 for the PROCESS flags may make the OS unstable. Please see ccSetPriority in CommonCode.bmx for more information. Note that when the game is paused or suspended (minimised or loss of focus) that the thread priority will be returned to normal. |
| ||
| A note on scrolling in BMax: Even though my scrolling moves at floating point values (to maintain internal smoothness) it has to be drawn at rounded integer values. This results in slight unsmoothness (the moire effect) as the floating point values are rounded as the tiles smooth down the screen. If you don't round the coords before drawing the tiles, the tiles anti-alias at the edge and this gives them a flickering appearance. I added a 1-pixel empty border to the tiles to counteract this and it looks better but is still flickery a bit - however the tiles DO move very smoothly. So it was a choice between lush smooth + flicker or not-so-smooth and no flicker, and I chose the second one. However, last night, thinking back to my Amiga days, I was wondering about using a pixmap twice as big as the screen and drawing the tile map to that and updating each new row Amiga-style. Then I can draw the entire texture to the screen at a floating point coord and it'll look lush! however, the texture would be 1200 pixels tall (bigger thanmany cards' 1024 limit), sigh, unless I had a game HUD 79 pixel tall...This would result in lush flicker free scrolling, really top quality. But I'm worried the pixmap updating and drawing to screen could be a bit slow... Of course I could just look the update to 60Hz and move 60 pixels per second and it would lock very nice EXCEPT that in windows mode it wouldn't be 60Hz so it would look crap. Also you can't rely on the Hz being achieved, plus what if someone has VSync off? That's why my framework doesn't lock anything it uses fixed rate logic and delta time. I could removed windowed mode but no portals would accept the game. |
| ||
| Great demo GA. You really have a solid package there which I have recommended on different forums. Keep it up! |
| ||
| Why don't you create a single mesh and just alter the UV's based on the tile that needs to be shown? Obviously you'd need all the tiles in one texture - but you should be doing that anyway. By using a single mesh you won't have any issues with so called "flicker" or having to draw at integer values, you'll also be saving overheads since you'll be able to share vertices (in most cases) and if you're using VertexBuffers the vertices will be maintained on the GFX card freeing up pipeline for other nice things :) |
| ||
I don't know if it was meant to do this but I just left the thing to fly by itself and it got to this point: |
| ||
| AJirenius: Thanks man, that's great! Matty: Yeah the array is 1000 tiles long and there is no "end level" detection coded so you just fly off into space like Enterprise. Indiepath: Regretably I don't really understand what you are talking about. I use BMax at a top level rather than a low level. I gather UVs are like the top left coords within a texture that it get's drawn from there. I do have all my tiles in one texture. The flicker is just at the edge of the tiles which are drawn at floating point coords because BMax (well the 3D card) anti-aliases the edges, and thus two edges together don't look cool as the tiles move down through various floating point coords. So I'm note sure how your method would get round that. My idea is to draw all the tiles (as laid of for the leve map) onto one big texture and scroll that, but continually update the big texture. |
| ||
| My idea is to draw all the tiles (as laid of for the leve map) onto one big texture and scroll that, but continually update the big texture. Totally the wrong way to do it. Have a look at this terrain model and just imagine it being flat : http://www.toymaker.info/Games/html/terrain.html |
| ||
| But it sounds the same. The big texture is only 2 screens tall and I'd only show one screen's worth whilst drawing to the other screen's worth. You are talking using the 3D card properly or something? Also how do you know there wouldn't be this anti-aliasing flicker on the tile edges when drawn at floating point coords - this would occure if they are drawn separately? Aha, maybe you are saying draw all the textures onto a "mesh", whatever that is, that is screesized and draw that on-screen? I dunno. Maybe you should code an example ;-) |
| ||
| yeah I should make an example - but after xmas :) And yes I'm talking about using the card properly. There won't be any flicker as the images will share vertices. Your issue is that your vertices are ever so slightly offset (unless you use Integers), the offset is amplified by the GFX card as it attempts to render them properly. This is a mesh created by BMAX to display an image:  If you don't align exactly (non Int) then you will get the problems you are talking about. I'm suggesting you create a mesh like this (notice the triangles share vertices) :  Now everything will be perfectly aligned - provided you texture it correctly :) |
| ||
| beginning to understand but those pictures of red Xs don't help ;-) |
| ||
| red X? oh you use IE :P Have a gander here : http://www.blitzmax.com/codearcs/codearcs.php?cat=12 - tis all you need |
| ||
| red X? oh you use IE :P Most people do. :-P |
| ||
| OK thanks. Interesting... |
| ||
| It was a lot harder to get the scrolling perfect on the Amiga Why don't you create a single mesh and just alter the UV's based on the tile that needs to be shown? Obviously you'd need all the tiles in one texture - but you should be doing that anyway. By using a single mesh you won't have any issues with so called "flicker" or having to draw at integer values, you'll also be saving overheads since you'll be able to share vertices (in most cases) and if you're using VertexBuffers the vertices will be maintained on the GFX card freeing up pipeline for other nice things :) hahahahahah. Im glad you asked for an explination. Thing is, I know we can rely on Indie to give a good example after the holidays. So Ill just post that in the "Things I dont need to try and understand yet" |
| ||
| Not very smooth here Grey. :-( |
| ||
| Not very smooth here Grey. :-( Do you mean because it's using integer coords for the scrolling or is there some worse smoothness issue like big jerks? Anyway it's not doing anything special, just using the framework timing in a normal way - it look spretty good on my PC. To be honest, that's the best you can get out of BMax without Indie's fancy mesh method, or without locking the refresh rate to 60Hz which isn't very compatible with a wide range of PCs. Then there's boosting the thread priority to avoid big jerks but really a game shouldn't need to do that. |
| ||
| [without locking the refresh rate to 60Hz which isn't very compatible with a wide range of PCs] > I don't understand that, because 60hz is the default mode for every screens. |
| ||
| If your game has a windowed mode, you can't lock it to 60Hz, it has to be the desktop res, so if your game does logic after every flip it will run faster in windowed mode due to the desktop Hz being 75 or 85 or whatever. Also if the user has VSync off, your 60Hz won't be 60Hz, and you game will run at Max Speed, not good. |
| ||
| No big jerks - but it judders a little. |
| ||
| same here |
| ||
| The slight juddering may be the integer coords for the scrolling. Have you played anything else that you could say is smoother? |
| ||
| It judders here too. It's like it's trying to scroll in steps of x.25, x.50 or x.75 instead of just 1, 2 or 3 + pixels each frame. without locking the refresh rate to 60Hz which isn't very compatible with a wide range of PCs. Really? - I doubt there are a *wide* range of home pc's that don't support 60hz. |
| ||
| I didn't really word that right. What I mean is if I lock to 60Hz and run it on a wide range of PCs, it's not going to work well on some of them, i.e. VSync off ones or ones that force a certain Hz in certain screen modes e.g. 85Hz in 800x600. Plus, like I said, you can't lock to 60Hz in windowed mode and if you want your game on the portals, you need a windowed mode.... Yes, the scrolling is moving at non-integer amounts per frame and rounding the y coord to draw. It's not possible to scroll at integer amounts per frame unless you lock the Hz, which you shouldn't really do (see the first part of this post) and so on ... It would look nicer if the inital speed on my game was > 1 pixel per frame so at least it's not moving at sub 1 pixel amounts per frame. |
| ||
| [windowed mode] >Yes... -Try to draw things with floor# or ceil# to get smother moves. -For Windowed, try timer + vwait... you don't have more choice :( |
| ||
| I'm not dissing your work here Grey, just want to make that clear :) OK, how about having the game logic working at 60fps, so those who want uber smooth graphics (the geeks) can set X resolution to 60hz. Now if the logic is set to 60fps, then those already running at 60hz will have silky smooth and those at higher frequencies will still get smooth graphics, but not silky smooth. At the moment it does run all juddery and it looks like it struggling to keep up. In retrospect your framework demo runs nice and smooth, particularly the purple grid scrolling vertically in-between levels. |
| ||
| Réno: I'm already rounding the coords to draw them and that's why it looks a bit juddery. time+vwait would work but I prefer the fixed rate logic to catch up with framerate dips etc. Qube: I'm not dissing your work here Grey, just want to make that clear :) That's cool dude, thanks. Yeah running both game logic and FPS at 60Hz would be nice and smooth in full-screen mode on most PCs (if I only scroll in whole pixel amounts), but not in windowed mode unfortunately as it will most likely be a different FPS. I guess that'll teach people not to run arcade games in windowed mode ;-). My framework demo looks smooth on the purple grid because it's drawing at floating point coords and the image is actually one large image not tiled. Maybe I'll post my floating point version of the scroller and you'll see how smooth it is, but there is a tiny flicker on the tiles... I've look at lots of pro platform games and shooters on portals and they all have some kind of jerks (unless they are pure 3D), some don't even VSync in windowed mode (or at all!) so there's tearing which is yucky. |
| ||
| ***OK everyone, I've uploaded a floating point coord version for comparision. Please see the top of the post.*** See if the "juddering" goes away - it should do, but you may see flicker on the edges of some of the tiles due to AA. Also the juddering only occurs at the slowest speed really i.e. when it's moving less that 1 pixel per frame. Same for the AA flicker too. Go over a green arrow and it should go away. If you get any big jerks, that's your OS doing some other task and the framework catching up (it's what 3D games do, but it looks more natural on them), this can't be avoided if you don't want the game to loose time - the only alternative is to pause and loose time which isn't so good either. |
| ||
| I think i would go with a real mesh instead of just flat texturing. Looks better, feels better, more fun and freedom. By the way wasn't there once a discussion about 2d shooters and some nice links for these? Does anyone remember one of those? |
| ||
| Yeah, just that I know nothing about it. Did you try the demos? |
| ||
| Do they run on a mac? |
| ||
| Not yet, sorry. |
| ||
| Pssst! Stole myself to the computer for some minutes...of course nothing finished but it shows such a mesh scrolling...now where are those guys who do nice terrains again?! Runs fullscreen with 60 fps on my mini (1.25 g4). http://spielwiese.marune.de/_uni/_tmp/baller.html Obviously this benefits when you want to rotate the camera angle a bit (zaxxon...) but it's not in there yet... ;O) |
| ||
| Neat, what did you code that in? It's not smooth either, I guess because it's in a browser window... |
| ||
| Neat, what did you code that in? It's not smooth either, I guess because it's in a browser window... Grey right click on the game screen to have more options (fullscreen and link to Unity website) |
| ||
| Thank Gub, yeah it's nice and smooth in full-screen mode. |
| ||
| @Grey Which Browser are you using? Runs without any glitches on Safari in windowed mode too. Firefox2 still makes some problems at the moment. |
| ||
| Ie of course ;-) I'm mr Mainstream when it comes to apps. The FPS just jumps around a lot whereas full screen it's 85Hz. |
| ||
| 6 or 7 Mr. Mainstream? ;O) |
| ||
| 6, see, still mainstream ;-) |
| ||
| Oh sorry my mistake! ;O) |
| ||
| Anyway nice code, I obviously need to figure out this MEsh stuff for ultimate PC scrolling. |
| ||
| Tried out another perspective and a little bit shooting (lmb/rmb or v,b)... http://spielwiese.marune.de/_uni/_tmp/baller2.html Man i've no time for this but it is fun to do.. :O) |
| ||
| So I'm confused. How the hell is your game playing in a browser and what are you using to write it? Reminds me of the Aistrike games, ever play them? They are pretty cool. |
| ||
| This is some advanced Javascript i'm using...nah kidding... ;O9 As hub already mentioned it's just Unity which is able to publish off- and online for win and osx and those weird widgets. |
| ||
| so like it's b3D then right? |
| ||
| taumel : interesting stuff, but is it possible to apply this with bmax, into 2d flat game, not 3d ? |
| ||
| @Grey Yep but it's much more advanced. As Blitz3D it's main purpose is 3D. You can also do 2D stuff with it (orthogonal camera view,...) but it would be much more complicate than just to do it in BlitzMax. So if you want to do 2D and offline i wouldn't recommend it and stay with BlitzMax. @Hub Nope, unity is as written above a complete 3d ide. Maybe it would work if you hack this and wrap that but i don't see someone doing it and if it would be allowed. |
| ||
| Yeah but the mesh idea should be possible in BMax. |
| ||
| Yes, that's the reason why i brought it up at all. I'm just faster setting up 3d stuff in unity than in BlitzMax and it's easier to show off as it also runs in the browser. That's why i did it this way. |
| ||
| I see. Anyway I'm not sure I'll do the mesh thing right now as I have some other things on my plate. I just wanted to make a "standard" scroller using normal old-school techniques so that people who have my framework can see and use the example code. Lots of Noobs get stuck on how to scroll, yet to me it's obvious, so hopefully they'll find it useful. Next up is a platformer demo... |
| ||
| Ahh okay i thought you wanted to make a shooter game and just for this case i would go such a route. If someone would do the media [gfx (a few nice level terrains, alien objects (flying and based on ground), hud), sfx (tunes, effects)] it really could be a funproject to make a small silly nice looking shooter. :O) |
| ||
| Yeah I feel like embelishing Speed Run (in the future as a hobby), but for now it's just a framework demo. If I was to make a pro shooter, I would probably investigate meshes as a solution. |
| ||
| @grey : hope your old school demo scrolling source soon ;-=) |
| ||
| hub: yeah I'll release it next week I think with a new framework update. |
| ||
| LOL, this gets me thinking of getting back into top-down shooters again. Thanks a lot... |
| ||
| Let's all make them, they are cool and I'd wanna play some Blitz ones :-) |
| ||
| Why should i care that it's done in Blitz, please?! Or in other words: Was Xevious written in Blitz?! |
| ||
| By the way http://www.youtube.com/watch?v=sY8__vjJYkA&mode=related&search= :O) When i listen to the two sounds it sounds a bit like Parallax from Galway. With shooting http://www.youtube.com/watch?v=yqwRIYFo0J8&mode=related&search= |
| ||
| weird video. I know the game though. |
| ||
| Yep Grey I am waiting for the platformer demo... I was gonna ask if the engine scrolled to the side instead of up and down... :) |
| ||
| the engine is done, I'm just refining the scrolling (see the BMax thread). |
| ||
| Cool cool! I normally deal with this by doing as you do, drawing it all, or as you also mentioned, Scroll the screen image and just draw new blocks. I used the technique in my Mushroom game because on newer machine B3D started to slow down. You don't really have the ability to "scroll" the screen directly in blitzmax though do you, since it normally just redraws everything on "flip" I think. Either way, Max and 3D means its fast enough to draw everything anyway, back when Blitzing Vram was the fastest way to draw, my old P133 could handle redrawing everything. Shame that a AMD Athlon 64 4200+ Dual core can't handle it.... (Yup, I know its not the processor but the Gfx card and its interface that now causes the issue.) |
| ||
| Yeah I can't scroll the screen in BMax :-( So anyway I've been sent some mesh code that I'm looking into. For now anyway this is a fine "standard" way to get scrolling in Bmax. |
| ||
| Is BlitzMax capable of doing smooth scrolling using either tiles or without using tiles? I have not really had much practice with BMax yet, so don't really know what it's capabilities are. Thanks |
| ||
| Enigma: It depends...If you use tiles and fixed the Hz to 60 and move by a whole pixel (or more) each frame it will be perfectly smooth. However, if you want to use Delta Time or Fixed Rate Logic and not rely on 60Hz being the refresh rate (like in windowed mode for example), then you have two options a) round your floating point srolling coords to integers, it'll be reptty good but ever so slightly jerky (see the first demo posted above), but this is unavoidable and lots of other games do it or b) draw at floating point coords which look smoother when it moves but the edge of the tiles show an anti-aliasing "flicker" sometimes (see the second demo posted above). A 3rd option exists which is using tiles on a mesh so the vertexes are shared. But this is beyond the scope of my framework at the moment. Hope this clears things up. |
   |