MGE Environment Test (BlitzMax)

Community Forums/Showcase/MGE Environment Test (BlitzMax)

MGE(Posted 2008) [#1]
I updated my engine (BlitzMax) to support wide screen modes by adding the code Sswift made available. I don't have a wide screen monitor so I'm hoping a few of you can download the demo and run it in both windowed / full screen mode and let me know if it's working ok. Thanks!

Technically, this demo is using fixed rate logic with no jitter correction, so it may look less than smooth occasionally.

(600k)
http://jgoware.com/mge/mge032808.zip


johnnyfreak(Posted 2008) [#2]
it works fine!
;)


EnigmaticGames(Posted 2008) [#3]
1440x900 is my resolution so I couldn't exactly tell how well it works, it displays fine in windowed mode, but full screen mode still leaves a lot of "black" area


GfK(Posted 2008) [#4]
Works fine, I think. I get a black bar about an inch high top and bottom, everything else is white. Dunno if its supposed to be like that, or you're using OpenGL (Blitzmax under GL doesn't like Intel GMA chipsets).

1280x800 res.


TomToad(Posted 2008) [#5]
Using 1440x900, looks fine in both windowed and fullscreen when using highres, however the lowres switches to 800x600 and puts black bars on the top and bottom causing major stretch. For some reason, my system doesn't support less than 800x600.
When you make your game, you might want to make a user option for setting resolution and aspect ratio in case the program doesn't autodetect correctly.


MGE(Posted 2008) [#6]
Thank you for the replies. I updated the demo to correct a few errors, mainly it wasn't detecting a widescreen desktop, etc. If possible, please download again and give it a spin. The high/low res options just try to get a best fit at full and half game resolutions. Thanks!

(600k)
http://jgoware.com/mge/mge032808.zip


plash(Posted 2008) [#7]
I don't have a widescreen, but running in windowed mode with high res does a virtual 960x600.

Q: Is MGE out yet? if not do you have an estimate?


MGE(Posted 2008) [#8]
Hi Plash, yah the real intricate stuff it attempts to do is mainly full screen mode. Thanks for checking it out. MGE is not out yet, trying to get a real game done first before I release it. ;)


Grey Alien(Posted 2008) [#9]
Works fine in full screen and windowed mode. Explosions look lush. Yeah there is some jittering going on.


Stevie G(Posted 2008) [#10]
Works fine here. How about a stress test or something else to show us why this will be better than GA's framework etc...?


plash(Posted 2008) [#11]
Yeah there is some jittering going on.

I thought that was just other processes running, guess not!


MGE(Posted 2008) [#12]
Thanks SG - I did a small asteroids type game/demo lastt year you can check out here: http://jgoware.com/mge/downloads/asteroidblast.zip

MGE is not a framework and could never compete with GA's excellent work. MGE at it's core is just a sprite engine and something I'm hoping can be utitlized with any framework tool. ;)


Dreamora(Posted 2008) [#13]
Why compete with something that can work along with it nicely :)
Sharing benefits is always better then trying to compete needlessly.

I've actually linked in GAs as well as your feed to be up to date :)


Grey Alien(Posted 2008) [#14]
Yeah this sprite engine looks great. No reason both can't be used (same with SSwift's engine too). You could just use the MGE sprite type instead of mine. Mine is pretty flexible but it uses all the standard BMax draw commands, so if MGE uses faster drawing techniques it could be worth using instead. Having said that I've got some neat single-surface sprite code which has not yet been released yet...


MGE(Posted 2008) [#15]
The single surface (sprites all on 1 texture) doesn't really speed things up because there is no internal batching taking place under the hood. But it does make things a little easier as far as video ram, object placement, etc.


Grey Alien(Posted 2008) [#16]
Yeah there's a VRAM saving. But also if you are drawing a load of different particles and they come from the same texture, the GPU won't need to switch textures so there should be a saving. Of course you can't guarantee it'll draw them in order, but if you pump out 200 particles in a row via BlitzMax there's a good chance they'll be drawn together, agreed?


MGE(Posted 2008) [#17]
"Of course you can't guarantee it'll draw them in order, but if you pump out 200 particles in a row via BlitzMax there's a good chance they'll be drawn together, agreed?"

Hmm... not sure what you mean? I havn't had any problems with images not being rendered in the order they were drawn via code. Or is there something I'm not getting? Thanks.


Grey Alien(Posted 2008) [#18]
Well I thought that's what you were getting at when you said about batching but I must have misunderstood. Do you agreed that reduced texture swapping will speed up particle drawing?


MGE(Posted 2008) [#19]
Ahh....ok. ;) Reduced texture swapping does help performance, it's not the key to 1000's of particle rendering though, at least not in my tests. When you get a chance, research DirectX 9 "Sprite Object". It has batching, sorting, built in and there are tons of developers using it for their 2D games. In one call you can scale, rotate, color, etc, AND get batching support. I'm hoping there is an official DX9 (Skip DX8, it didn't get near the upgrade DX9 did) module for Blitxmax in the coming months. It will solve any and all 2D rendering issues.


Grey Alien(Posted 2008) [#20]
I see, very interesting. I may move to DX9 one day, but at this point it would remove too much of the market for me (maybe less of an issue for action games?)


MGE(Posted 2008) [#21]
Agreed. For typical casual game performance, Blitzmax/ DX7 even with the built in functions is fine. Don't get me wrong, it is certainly possible to write a better, batch driven blitting system for BMax/DX7 but it may not be worth it in the long run, because if you need to blit a ton of particles, sprites, tile layers, etc, etc, you're probably appealing to someone outside the typical casual audience, who probably has a much better pc configuration for games anyway. ;)

Btw, the Intel boards on recent Dell laptops is a speed demon and runs everything I throw at at full refresh speed. This is very good news if you ask me. :)


Grey Alien(Posted 2008) [#22]
Cool. When bog standard laptops are able to run Casual games with tons of graphical effects nice and smooth then we can forget all this techy stuff ;)


MGE(Posted 2008) [#23]
Exactly! Seriously, I bit tweaked my arse off on the Atari's 8bit(6502), Atari ST(68000), doing all kinds of assembly to gain a few cycles. With today's technology, we "should" be able to focus more on game design compared to writing low level system level routines, etc.

Seriously, I am betting on sometime in the next year or 2, there is going to be a stable Max2D Driver for DX9 that will give us a much needed render upgrade. And at that point hopefully, DX9 will be what DX7 is today. ;)


Grey Alien(Posted 2008) [#24]
Hope so too. It'll need a damn good test of course. I hope that BMax is a long term solution foe me too. I'd hate to have to change language in a year or two (and have to build up a new engine from scratch - actually I'd just buy one in C++ or something)