What you need/want in a 2D graphics engine?
Author
I am working on a 2D graphics engine for VB.NET or C# with Managed DirectX that is fully hardware accelerated and my goal is to make it robust, fast, and easy to use. Right now I have the robust and fast stuff done. So now I am adding features and I would like to know what kinds of things you want in a 2D engine. I want to keep it all fairly simple to use, but at the same time I dont want to limit the functionality too much (Other than limiting it to 2D). I also dont want to limit the functionality to just one genre. It should have all the necessities for doing graphics for a 2D sidescroller/RTS/RPG/adventure game/puzzle game whatever.
I am planning to include (or have already included)
-Switching between fullscreen/windowed while running
-Device loss is taken care of for you
-Built-in frame timing
-It has a camera that you move/zoom in&out/rotate
(like DirectX only you dont have to mess with vectors)
-Output is automatically scaled to the resolution you are using
(so you can program in one resolution and it will look the same in any resolution)
-Translucency
(Texture and Sprite)
-Rotation
-Colored sprites
-Simplified drawing functions
(i.e. DrawSquare/DrawRectangle/DrawLine/DrawIsotile)
-Easily draw fonts
What am I forgetting? What other features should I include? What features would you want?
Keep in mind it a graphics (not game) engine.
maybe you already covered this or maybe you dont need it with the system your working off but your going to need some kind of collision detection for most games
edit: after reading that note on the bottom i dont really know if my comment is valid because that would be more physic engine based
edit: after reading that note on the bottom i dont really know if my comment is valid because that would be more physic engine based
Heya,
Here's a somewhat basic list of what I'd be interested in in a 2d graphics core.
Window init / setup
Enumeration [to an array of classes]
Make limits [d3dcaps or whatever they're called] easy to access (maybe a Caps_MaxTextureSize() function or whatnot)
Test specific config [eg ModeAvailable(800,600,32)]
Suggest config [eg NextBest(820, 620, 32) scales to 800,600,32 would be cool]
Set window style programmatically [ie remove close box etc]
Blitting stuff
Direct [fast] blit from texture (I think D3DX has this)
2D rectangles
Shield the user from needing to make 2 tris
Allow input in either absolute pixel, [0,1] or scaled from resolution (eg [0,800] scales automatically to [0,1]) form
Allow texture coords to be calculated automatically
^ Depending on the style of input that you're using.
if using abs pixel, calculate from rect size how not to squash texture
I'd use ortho transforms, so that there's no alteration on the z axis.
Texture stuff
No limits to number of textures loaded
[option to] Reference textures by ID rather than filename
Cache everything by texture to minimise state changes
Animation core
Allow animations to be loaded, where you specify the rectangle and animation frame, and the core determines the part of the texture/which texture to use from some list.
Automatically running animations [tied in with your timing thingy] (example looping background animations or triggered animations)
Text
I'd allow 2 methods, a wrapper for bitmap ASCII tables or DrawFont [whatever it's called]
Make sure to allow different colours of text
HUD/background stuff
I know it isn't a game engine, but maybe a list of sprites / text items that are automatically drawn each frame. Simply means you'd have to wrap your draw calls inside a 'drawBackground' and 'drawForeground' call.
Optimisation stuff
Cache everything! I'd throw everything into a big vertex buffer before you draw it, because DrawPrimitive() is *SO INCREDIBLY SLOW* if you're only sending off batches of a few tris.
Other cool miscellany
An external image processor would be really quite cool, allowing you to pack your images, try out your animations, rotate 2d textures to make isotiles and whatnot. Asset theft is a concern, you don't want hundreds of .dds files, or worse, .bmp or .jpg etc just lying around for the taking.
Yeah, a couple of thoughts on my part. A lot of the details and complexity could be hidden by you in the interface, so make sure that your interface is really clean, and it'll make sure that more people use it / it's easier to use.
//end rant
CJM
Here's a somewhat basic list of what I'd be interested in in a 2d graphics core.
Window init / setup
Enumeration [to an array of classes]
Make limits [d3dcaps or whatever they're called] easy to access (maybe a Caps_MaxTextureSize() function or whatnot)
Test specific config [eg ModeAvailable(800,600,32)]
Suggest config [eg NextBest(820, 620, 32) scales to 800,600,32 would be cool]
Set window style programmatically [ie remove close box etc]
Blitting stuff
Direct [fast] blit from texture (I think D3DX has this)
2D rectangles
Shield the user from needing to make 2 tris
Allow input in either absolute pixel, [0,1] or scaled from resolution (eg [0,800] scales automatically to [0,1]) form
Allow texture coords to be calculated automatically
^ Depending on the style of input that you're using.
if using abs pixel, calculate from rect size how not to squash texture
I'd use ortho transforms, so that there's no alteration on the z axis.
Texture stuff
No limits to number of textures loaded
[option to] Reference textures by ID rather than filename
Cache everything by texture to minimise state changes
Animation core
Allow animations to be loaded, where you specify the rectangle and animation frame, and the core determines the part of the texture/which texture to use from some list.
Automatically running animations [tied in with your timing thingy] (example looping background animations or triggered animations)
Text
I'd allow 2 methods, a wrapper for bitmap ASCII tables or DrawFont [whatever it's called]
Make sure to allow different colours of text
HUD/background stuff
I know it isn't a game engine, but maybe a list of sprites / text items that are automatically drawn each frame. Simply means you'd have to wrap your draw calls inside a 'drawBackground' and 'drawForeground' call.
Optimisation stuff
Cache everything! I'd throw everything into a big vertex buffer before you draw it, because DrawPrimitive() is *SO INCREDIBLY SLOW* if you're only sending off batches of a few tris.
Other cool miscellany
An external image processor would be really quite cool, allowing you to pack your images, try out your animations, rotate 2d textures to make isotiles and whatnot. Asset theft is a concern, you don't want hundreds of .dds files, or worse, .bmp or .jpg etc just lying around for the taking.
Yeah, a couple of thoughts on my part. A lot of the details and complexity could be hidden by you in the interface, so make sure that your interface is really clean, and it'll make sure that more people use it / it's easier to use.
//end rant
CJM
I am doing something similar for OpenGL, and you may be interested in some of the replies in my thread about it here ("Wishlist for 2D SDL/OpenGL library").
Hardware accelerated alpha blending.
Ability to render tens of thousands of sprites at high frame rates. For examples of where this might lead game designwise, please see the results of Indie Game Jam 0.
Once you start worrying about 10K..100K sprites on the screen at once, you start worrying about 2 things:
- how am I going to keep all those sprites from simply overlapping each other?
- how the hell am I going to control all of those sprites?
For instance, several of the games in the Indie Game Jam 0 could just have easily been implemented with 1 great big sprite for some monsters, rather than tons and tons of little ones. As it stands, you often couldn't tell if you were being approached by a horde of 20 sprites or 20K sprites.
Ability to render tens of thousands of sprites at high frame rates. For examples of where this might lead game designwise, please see the results of Indie Game Jam 0.
Once you start worrying about 10K..100K sprites on the screen at once, you start worrying about 2 things:
- how am I going to keep all those sprites from simply overlapping each other?
- how the hell am I going to control all of those sprites?
For instance, several of the games in the Indie Game Jam 0 could just have easily been implemented with 1 great big sprite for some monsters, rather than tons and tons of little ones. As it stands, you often couldn't tell if you were being approached by a horde of 20 sprites or 20K sprites.
Author
Wow, you really thought about this CJM.
I'll address your ideas in the same format
Window Init / Setup
I'm handling all this stuff for the user. So I probably wont let them access device caps, rather I will automatically fall back on the next best thing. (1600x1200 not supported so goto 1280x1024)
Also the user won't have direct access to the form where things are being drawn (It's just too easy to break DirectX if you mess with stuff on the form) but I'm giving access to some stuff like mouse/keyboard events and everything else you could want to have.
Blitting Stuff
Don't worry its all Direct3D, ITS FAST :), All fully hardware accelerated wherever possible.
2D Rectangles
The user doesnt have to deal with triangles, I'll have simplified drawing function (as i mentioned before). And, if they really want it the ability to set each point on the quad (to make non-rectangular sprites).
I'm not giving the programmer absolute pixel drawing capabilites, instead everything is relative to the aspect ratio they give(normally 1.33333, but you can change it to whatever you want), this way the game will look consistent no matter which resolution the user chooses.
Yes I am using ortho transforms, and I will have the ability to rotate the entire.(while keeping it flat)
Textures
The only limit will be whatever MDX's limit is(if it has one)
Textures are referenced by an Integer (only use filename when loading them)
There will be lots of texture caching.
Animation Core
Im not currently planning to support any sort of animation feature. It should be easy enough to program animations by using the other elements of the engine. And most games dont handle animation a "standard" way.
Text
I was already planning to use the DrawFont in DirectX, i hadn't thought of a wrapper for custom textured fonts. It won't be a priority but I will try to make something like this.
HUD/background stuff
This part is kinda complicated. Im not keeping lists for the user or anything like that. Basically there are 4 buffers that they draw to. (StaticScene/DynamicScene/StaticScreen/DynamicScreen)
The programmer uses DynamicScene for stuff that changes every frame(i.e. spaceships/projectiles/anything that moves in context to the scene)
They use StaticScene to draw anything that is stationary (i.e. terrain/trees/stars/background art) this stuff doesnt change(often) and would only be loaded when you start a level or load a map.
The others (StaticScreen/DynamicScreen) are for screen sprites. Dynamic would be for the cursor and any sort of motion in the GUI. Static would be used for buttons and other non-moving GUI elements.
I know this all sounds pretty complicated but I am gonna draw graphical representations of it to make it easy to understand. And it is also a lot more flexible than it sounds.
Optimization stuff
Don't worry about speed. This is my 5th engine rewrite (I keep rewriting because I am unhappy with performance/flexibility etc.) and as soon as I started writing it I knew I would be sticking with this one. Its fast, flexible, and robust. I'm doing a lot of caching thats the main reason for the static buffers. And its running very fast at the moment (1000+ fps when I do immediate presentation) although I'm just rendering a few polys, some text and rotating the whole screen
Other cool miscellany
I'm going to support loading textures from resource files as well as from image files. And I will probably make a preview app that lets you load a texture and draw(rotate/translucency/color etc.) it with the engine, however it would be pretty easy to write this yourself with the engine as is.
I'm working really hard to make the interface easy to use while still not hitting the performance significantly.
Another thing I forgot to mention is that my engine is an inheritable class (you implement it the same way you do System.Windows.Forms.Form) so it would be easy for someone to write a general engine for a particular type of game (i.e. sidescroller/rts/rpg)that inherits from my engine and is also inheritable. Making it very easy to extend functionality engine-wise.
For example, Your game could inherit RTS which inherits Animation which inherits IsotileEngine, which inherits my engine. Of course this is only if my engine becomes popular :)
Also, I am not planning on licensing it or anything, it will be totally free, all I will ask for is my name and the name of the engine(which I'm not 100% sure of yet) in the credits.
Thanks for the post CJM, I'm out for the night, stupid 10:00am classes...
I'll address your ideas in the same format
Window Init / Setup
I'm handling all this stuff for the user. So I probably wont let them access device caps, rather I will automatically fall back on the next best thing. (1600x1200 not supported so goto 1280x1024)
Also the user won't have direct access to the form where things are being drawn (It's just too easy to break DirectX if you mess with stuff on the form) but I'm giving access to some stuff like mouse/keyboard events and everything else you could want to have.
Blitting Stuff
Don't worry its all Direct3D, ITS FAST :), All fully hardware accelerated wherever possible.
2D Rectangles
The user doesnt have to deal with triangles, I'll have simplified drawing function (as i mentioned before). And, if they really want it the ability to set each point on the quad (to make non-rectangular sprites).
I'm not giving the programmer absolute pixel drawing capabilites, instead everything is relative to the aspect ratio they give(normally 1.33333, but you can change it to whatever you want), this way the game will look consistent no matter which resolution the user chooses.
Yes I am using ortho transforms, and I will have the ability to rotate the entire.(while keeping it flat)
Textures
The only limit will be whatever MDX's limit is(if it has one)
Textures are referenced by an Integer (only use filename when loading them)
There will be lots of texture caching.
Animation Core
Im not currently planning to support any sort of animation feature. It should be easy enough to program animations by using the other elements of the engine. And most games dont handle animation a "standard" way.
Text
I was already planning to use the DrawFont in DirectX, i hadn't thought of a wrapper for custom textured fonts. It won't be a priority but I will try to make something like this.
HUD/background stuff
This part is kinda complicated. Im not keeping lists for the user or anything like that. Basically there are 4 buffers that they draw to. (StaticScene/DynamicScene/StaticScreen/DynamicScreen)
The programmer uses DynamicScene for stuff that changes every frame(i.e. spaceships/projectiles/anything that moves in context to the scene)
They use StaticScene to draw anything that is stationary (i.e. terrain/trees/stars/background art) this stuff doesnt change(often) and would only be loaded when you start a level or load a map.
The others (StaticScreen/DynamicScreen) are for screen sprites. Dynamic would be for the cursor and any sort of motion in the GUI. Static would be used for buttons and other non-moving GUI elements.
I know this all sounds pretty complicated but I am gonna draw graphical representations of it to make it easy to understand. And it is also a lot more flexible than it sounds.
Optimization stuff
Don't worry about speed. This is my 5th engine rewrite (I keep rewriting because I am unhappy with performance/flexibility etc.) and as soon as I started writing it I knew I would be sticking with this one. Its fast, flexible, and robust. I'm doing a lot of caching thats the main reason for the static buffers. And its running very fast at the moment (1000+ fps when I do immediate presentation) although I'm just rendering a few polys, some text and rotating the whole screen
Other cool miscellany
I'm going to support loading textures from resource files as well as from image files. And I will probably make a preview app that lets you load a texture and draw(rotate/translucency/color etc.) it with the engine, however it would be pretty easy to write this yourself with the engine as is.
I'm working really hard to make the interface easy to use while still not hitting the performance significantly.
Another thing I forgot to mention is that my engine is an inheritable class (you implement it the same way you do System.Windows.Forms.Form) so it would be easy for someone to write a general engine for a particular type of game (i.e. sidescroller/rts/rpg)that inherits from my engine and is also inheritable. Making it very easy to extend functionality engine-wise.
For example, Your game could inherit RTS which inherits Animation which inherits IsotileEngine, which inherits my engine. Of course this is only if my engine becomes popular :)
Also, I am not planning on licensing it or anything, it will be totally free, all I will ask for is my name and the name of the engine(which I'm not 100% sure of yet) in the credits.
Thanks for the post CJM, I'm out for the night, stupid 10:00am classes...
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
