rock steadty 60fps for 2D arcade game
BlitzMax Forums/BlitzMax Beginners Area/rock steadty 60fps for 2D arcade game
| ||
| Which out of all version of Blitz, eg. Blitz Max, Blitz3D, Blitz Plus will achieve a rock-steady 60fps for a 2D sprite based arcade game ? I know each version has its own pro's and conns and different way of going about things. |
| ||
| You can't guarantee 60fps from any language. It depends on the hardware. What's *most* likely to achieve 60fps? BlitzPlus. Myself, I code for 30fps, though. Always have. |
| ||
| All of them and none of them. I've known joystick drivers that will ruin the experience for any pc user. |
| ||
| getting 60 fps is a matter of: progrmming skill and/or hardware and/or what you want the game to do. my biggers problem is lack of skill and creativity. I may be wrong but I think it may be most programmers drawback. |
| ||
| Its mostly hardware - you can't blame the programmer. You can only drive a car as fast as it will go. You can't press the accelerator any further than the floor. |
| ||
| yes, but I would think of the car being the program. not the hardware. a well tuned program(optimized) by a well trained programmer will allways give better frame rate result than a program made by an amateur. -edit maybe not always. |
| ||
| so from those assorted comments and assuming the demands of the program would hardly stress an 800MHz Pentium with 256MB of Ram, is it safe to assume all versions of Blitz can manage it ? The reality of the project is less than 8 sprites on screen at once, at a fullscreen rez of 800x600. Think retro. I'm in a position now to choose which version of Blitz to use and I'd like the easiest route to 60Hz. I know each version goes abouts its business in different ways. I just want to pick a version that is most suited to this project. |
| ||
| Then BlitzPlus is probably best for your needs. |
| ||
| Naturally I suggest BMax and my framework. See the AOTMG demo and see how smooth that is on your PC. Also Bmax can have alpha blended sprites and draw at floating point coords, + add on scaling, rotation and transparency and it rocks for professional level games which BPlus can no longer match. |
| ||
| why don't you try the demo version of Bmax and Bplus. Do a program on each and see wich one perform best for you. I have both and I prefer programming in Bmax simply because of it's types, methods, use of OOP? and it's hardware use of graphics. you can't hardware rotate objects(wich will save alot of memory by not storing aframe for each angle rotation of an image), do transparencies and other stuf in bplus, if you are creative enough you can produce the same results with software in Bplus but it would be a lot slower. |
| ||
| If you are aiming for the lowest possible system specs needed for a 2D game w/ relatively low sprite counts, BlitzPlus is your best bet. BMax will require your users to have a 3D card. It's also a lot trickier/slower to do pixel operations in BMax. Max will however allow you to do easier/faster rotations and scalings. |
| ||
| Basically I used BPlus for 15 months or so and when I swapped to BMax I love every bit of it (except for the bugs and techincal problems with BRL have now fixed and others which I've figured out workarounds for). The OOP is great and the 3D card effects are brilliant fun. |
| ||
| Thanks for the comments. Having looked through the specs for BMax, my mouth is watering with all the features. Compared to console development, its interesting to note that each user will have different video hardware running at a variety of framerates. I'll have to delve into Blitz and see which is the best way to lockdown framerate with this in mind. Obviously I can't rely on the user's video card's VSYNC either. |
| ||
| you need either delta timing or fixed rate logic or both - hmm I wonder which BMax add-on has that in then? ;-) Also there are tons of posts about the topic on this forum. |
| ||
| Having looked through the specs for BMax, my mouth is watering with all the features. So you didn't really require what you suggested then. BMax is the best choice really - and for silky smooth movement see mister Grey there and his BMax add-on. |
| ||
| Aiming for the future I say go with BlitzMax. Your hardware requirements are the main factor in the graphics speed, based on how much stuff you want to animate. |
| ||
| Yeah, Blitz Plus is the past, Max is the future. My advice is to think of the future and not dwell on the past by developing for ancient(10 yrs +) technology. |
| ||
| Grey, is there any documentation on this "fixed rate logic" technique you mention ? |
| ||
| Yes, here: http://www.gaffer.org/game-physics/fix-your-timestep/ I used this in my framework + changed it a bit. Seems to work very well. |
| ||
| That's a nice set of tutorials, thanks for the link. |
| ||
| Or use a 320x240 resolution? lol Really, resolution increases the number of pixel substantially, compared to the old days of 320x200 or 320x240 or 320x256, nowadays at least 640x480 is the minimum and more likely 800x600 or even 1024x768. That's like 4-16 times the graphics to render. If you want to ensure 60fps you probably have to settle for 640x480. |
| ||
| That's a nice set of tutorials, thanks for the link. you are welcome but I just got if off this forum from someone else in the past. I bookmarked it though :-) |
| ||
| The only way to guarantee a solid 60fps is to get your user to lock their DirectX settings and refresh rates at 60fps/Hz. The results look wonderful then. But I think you should just accept that this is a PC, this is Windows, and just put up with the slightly blurry refresh rate, because I can't see this issue going away anytime soon. |
| ||
| yeah it's a bummer. There is no way to guarantee it on all PCs, so you have to pick a refresh rate, hope it get's set but meanwhile run your game at a high logic FPS and just draw whenever the card let's you. Maybe one day they'll be some standard "Arcade Mode" for PCs, that would be nice. |
| ||
| Yes it's certainly a pain - but do we even need to go above 60hz for flatscreen monitors? CRT's definitely because of the noticeable flicker. But they have to be in a minority by now surely? |
| ||
| I think you only really notice CRT flicker in windows, but not in games... |
| ||
| Yah I never knew of seeing any flicker on an amiga hooked up to a tv at 50hz, so it should be fine. |
| ||
| great comments guys thanks. Sorry to keep this going, but I find the topic really interesting.... I appreciate the PC isn't ideal for rock-steady 60fps and ultra smooth movement, but something is bugging me... For example if I fire up MAME and play something on there, framerate seems totally smooth and non-jerky. I'm thinking, perhaps its not so much a limitation of the PC, but more of Blitz or my programming skill(most likely!). I have to qualify that and say so far I've only used my Blitz3D, so I've yet to check it I can get better results with BlitzMax. In days or yore, if I was working on an arcade game in assembler for the Amiga, my game would run at 50Hz and I'd move the sprite say, 1pixel ever frame = 50pixels per sec. There were no timing issues to contend with. So on the PC, I have to contend with different users running different monitor rates(Hz) eg. 60, 85, 100, etc...so 1pixel per frame could be 60pixels per second on one machine or 100pixels on another. So I employ Delta-Time, and limit the framerate to say 50Hz. Now when I watch the sprite travel from left to right, it looks smooth 90% of the time, but every now and then it jerks along ruining the smoothness. Should I be using time based code for better results ? All the tutorials seem to steer you away from it. I wonder if BlitzMax is better equipped to do what I want than Blitz3D. I'll get the trial and have a fiddle. Any comments welcome |
| ||
| Basically the occasional jerks you get are normal due to the moire effect. Basically you an moving a non-integer value per frame yet drawing at integer coordinates (I assume) so sometimes it may move 1 pixel betweek frames and other times 2 pixels between frames = not so smooth. Thing is if you want you game to work in windowed mode, you HAVE to use this method because the desktop Hz can be *anything*. If your game is full-screen only you *could* fix the hz to 60 say and make everything move smoothly but there is no guarantee that the end-user's full-screen is 60 (it probably is but sometimes this can be tweaked in drivers etc, and what it VSync is off!), so really you should use delta-timing or fixed-rate logic. What my framework does is it draws stuff at non-integer coords (cos Bmax can draw at floating point coords by using some 3D card jiggery pokery) and this looks very smooth. Plus I'm using Fixed Rate Logic and Delta Time to ensure continued smoothness. If Bmax only drew at integer coods (like BPlus) it wouldn't look as good, it would have this jerking you are seeing. I understand as I used to code the Amiga in assembly and use 50Hz too... |
| ||
| If you move with a floating point coordinate and floating point add value it should be drawn with sub-pixel sampling and shouldn't just jerk ahead or back 1 pixel, should look smoother? Also on the Amiga you had the vertical blank interrupt which you could tap into - every 50th of a second an interrupt was generated which called a piece of code which perhaps signalled to a `WaitVbl` command to stop waiting, so then you could start your next frame. That way your frames were all nice and synchronized and since you were only dealing with one solid hardware display system you didn't need to worry. These days you're dealing with all kinds of refresh rates, all kinds of resolutions, all kinds of color depths, all kinds of levels of reliability in reporting vblank synchronization, all kinds of cpu speeds, all kinds of graphics cards, all kinds of driver reliability, etc etc Certainly thows some spanners in the works sometimes. |
| ||
| Grey you mention using BMax, which I note has a graphics command that can set the Hz of the fullscreen. So there'd be no need to use delta-time, if I set the fullscreen Hz to say 60 ? Your totally right in what you say about the difference between using floating point and integer numbers when adding to the x & y co-ord of a sprite. Floating point does look jerky in comparison. Question - if I knew I could get away with using integers and not need flotaing point numbers, si there a way to do this so it works across all different screen refresh rates? Can you give me a general description on the difference between delta-timing and fixed rate logic ? I know delta time may not be any use but if fixed rate logic could be of use, then I'd like to know about it |
| ||
| You don't need delta timing if your game is not going to slow down below the default framerate. If you can be sure its fast enough to never go below 60fps it will be okay using just Flip() at 60hz. And no integers are not accurate enough to look completely smooth. The use of an integer is actually a way of `rounding` a `real value` and locks it onto a grid of 1x1 pixels, which will cause your objects to jump to the grid location. |
| ||
| Dax Trajero: No way of using integers across different refresh rates. If you set graphics refresh to 60Hz full-screen and the graphics card can't handle it or vsync is off or whatever, you won't have 60Hz although I think you can tell Blitz to do the timing for you but then you may get vertical tearing as it won't always be in sync with the display. It depends what you are coding for. Fun? Well set it to 60Hz and move by integer amounts and enjoy yourself, it will look lush. Pro? Gotta use Delta Timing/Fixed Rate logic. Read here: http://www.gaffer.org/game-physics/fix-your-timestep/ hope this helps. |
| ||
| AngelDaniel wrote: "You don't need delta timing if your game is not going to slow down below the default framerate. If you can be sure its fast enough to never go below 60fps it will be okay using just Flip() at 60hz." Thanks AngelDaniel. Yep, the game is dead simple and will happily sit at 60Hz and never go below. I want a technique that will work across whatever the user's screen is refreshing at. Q: Can you keep track of the frame number each second ? That way, I'd just draw the first 60 frames each second, regardless of what refresh rate is being used eg. if the user is at 120Hz, I'd just draw 60 frames out of the potential 120 frames I could draw, each second. Or am I being daft ? ;-) "And no integers are not accurate enough to look completely smooth. The use of an integer is actually a way of `rounding` a `real value` and locks it onto a grid of 1x1 pixels, which will cause your objects to jump to the grid location." From my mock-up my integer based movement looks super smooth for what I'm doing. For example, for SIN/COS values, I'm using an integer based look-up table that works perfectly. |
| ||
| Wow!!! Just tried BlitzMax and checked out sprite movement across a 640x480 @ 60Hz fullscreen and it was creamy smoooooth. I tried non-integer co-ords like Grey Alien and AngelDaniel mantioned and it still works beautifully. Looks like BlitzMax is the way forward, although the built-in help isn't as verbose or as good as Blitz3D. Took me ages for example to find out how to do FULLSCREEN for goodness sake! I wonder how likely it is 640x480 @ 60Hz fullscreen is available on everyone's machine ? |
| ||
| In the case of CRT monitors it's a safe bet that they are all capable of 640x480 @ 60hz, as 60hz is a 'safe' setting that is usually used by default until changed. As for TFT/LCD monitors, I'm not so sure. The screen on my iBook runs at 60hz, but I don't think all monitors of this type use 60hz as their native setting. Others will need to confirm this. Having said all that, a lot of people are quite susceptible to the flicker you get at 60hz on a CRT monitor, myself included. As such, I generally don't play these games, as they soon start to give me a headache! If you're programming for fun then stick with 60hz. If not, then have 60hz as default, but allow the user to change it somehow if they want to. |
| ||
| I wonder how likely it is 640x480 @ 60Hz fullscreen is available on everyone's machine ? While the vast majority of systems will support that resolution, more and more LCD screens (and laptops!) now use a wide-screen format, and not all of these support the 640x480 form factor. Pretty much every CRT will do 640x480@60Hz though. Most LCD's won't have a problem with the 60Hz, although some are locked to 70 or 75. (Not many will natively support refreshrates faster than that) However, BlitzMax can CountGraphicsModes() and GetGraphicsMode() to return a list of all resolutions and refreshrates that are supported on the hardware in question. (As reported by the video card drivers, which account for any limitations imposed by the the monitor itself as long as it's either a plug & play monitor, or the monitor drivers are installed) |
| ||
| Hello. Not sure whether it's the graphics card (ATI Radeon X800) or the TFT but I can't get my monitor down to 640*480 - 800*600 is the minimum allowed. Goodbye. |
| ||
| Not sure whether it's the graphics card (ATI Radeon X800) or the TFT but I can't get my monitor down to 640*480 - 800*600 is the minimum allowed. Did you actually try that from within Blitz itself? Windows XP by default won't allow you to set a desktop size smaller than 800x600, but will still allow games to open their own 640x480 screen. |
   |