Page 2 of 2

PostPosted: Sun Feb 04, 2007 3:08 am
by Sgt. Sparky
I'm still exited bout' it! :D :D :D :D :D *falls over dead from exitement*

PostPosted: Sun Feb 04, 2007 7:14 am
by Joshua Worth
:o openGL?! That will be cool. So you will be using SDL and OpenGL at the same time? Also, will it not allow you to export to mobile devices or something?

PostPosted: Sun Feb 04, 2007 1:37 pm
by makslane
Currently I have an engine version running over OpenGL, but only works with accelerated cards. I'm trying optimize to run at a good speed with software version of OpenGL.

There are new PDAs and cell phones with support to OpenGL ES in hardware. So, I think OpenGL is the right choice.

PostPosted: Sun Feb 04, 2007 8:05 pm
by morcior
OpenGL is a great choice .. it will speed things up a lot in windows/linux I just hope you keep compatability for pocket pc games.

Only very modern PDAs support the opengl standard you mentioned, so I would think it will be best if you retain the SDL rendering engine for use in Pocket PC exports and other devices which do not have 3D graphical hardware support... or there could be 2 options:

"Export for PocketPC (OpenGL ES)"
"Export for PocketPC (SDL)"

How about pre-rotated sprites?

PostPosted: Fri Feb 23, 2007 3:33 pm
by Schprlock
How about pre-rotated sprites?

At least for me that could be really useful. When you add an animation to an actor, it would be great if you could add a 1 frame animation (just an image) and set some flag or a field with the number of frames.
In the begining of the game, at runtime (or at compile time), Game Editor would generate those animation frames. Because they would be pre-rendered, there would be no performance impact (maybe an extra tenth of a second when starting the game if rendering would occur at runtime).

Rendering at compile time would be good for speed. Rendering at runtime would delay the start of the game slightly, but it would keep file size lower (not that it would be relevant for a small number of sprites, in either situation).