Quote:Original post by Jemburula If the game will be 2D why not just use SDL and forget OGL for now?
Mainly because I suck at drawing on the computer and I'm not sure how to do my own art. I didn't know SDL provided graphics. I thought it was more of an interface to the hardware?
Quote:I agree with Jemburula. Unless your doing some whacky rotations of images or other things that a DOS game probrably didn't use, you'll find it easier to use SDL alone.
Not whacky rotations, but I want to create a better looking DOS game with nice explosions and a dynamic terrain. I'm not aiming for something with Oblivion's graphics, but I don't want EGA either ;)
I'm going to look into SDL and the possibilities of it. No point in using OpenGL if I can do the same effects with SDL ;) I want something that's easy on the eyes, not look "old" and can make one go "ooooh nice one!". I'm not sure if it's realistic with my skills, but the whole point is doing something and complete it. I'm doing this for fun and to learn some ropes along the way.
OpenGl will render faster than SDL, along with more options ( hardware alpha blending, not using pixel co-ordinates as draw co-ordinates, rotation and scaling... ) SDL will draw bitmaps and blend them, but beyond that you will need to get routines to do any more. SDL may be easier, but it doesnt take to much to turn an SDL image (or SDL_Surface) into an openGL texture, and use openGL for the rest...
Quote:Original post by Jemburula If the game will be 2D why not just use SDL and forget OGL for now?
@MdaG: Depends on your DOS game I guess.
I personally prefer using OpenGL+SDL as you get all the benefits of the graphics hardware (as previously mentioned by @rip-off).
ie. I can quickly render some cubes and stuff in OpenGL just by a few vertex definitions. Whereas with sticking to SDL, I'd need to put together a cube bitmap,etc.
I'd try and avoid writing the engine by grabbing something like HGE to use instead.
Richard "Superpig" Fine - saving pigs from untimely fates - Microsoft DirectX MVP 2006/2007/2008/2009
"Shaders are not meant to do everything. Of course you can try to use it for everything, but it's like playing football using cabbage." - MickeyMouse
I guess I'll have to play around with opengl and sdl before I make any decisions about it. I've never written an engine before and I only have some assumptions about how an engine works (and is). Closest thing I've been to using an engine is Java swing (which I wouldn't call an engine). So I still have some research to do :)
Maybe I'll just settle for an existing engine. HGE looks interesting :) Too bad it's Windows only :( Still, I'll take a closer peak.
HGE uses DirectX 8.1 so you are only on Windows. HGE was abandoned by its creator for over six months and now has been open sourced, so its future seems uncertain. I have witnessed and seen graphical lags with ATI cards running the HGE demos. Now that it is open sourced, it would be nice if it was cross platform.
If you stick to windows, you have your choice of PTK and PopCap too. Don't forget Allegro and ClanLib. Check the Game Programming Wiki for libraries and engines.
And don't forget Photon, like I mentioned before.
Think about what you have to do and what middleware can make it easier for you.
Create Window Resource Management Drawing Sprites Tile Map Sound Music Drawing Text GUI Particle Engine Animation Game States Special Effects
Using ready opensource engines/libraries will help you advance faster and will keep your motivation high. Reinventing the wheel will likely result in buggy small features and the end of motivation. Before you start writing anything look for some ready code that has it done.
For example: - GUI: check GUIs, make sure they are custimzable and easy to learn (I recomend CEGUI - full featured and many tutorials) - particle "engine": havent explored that one yet... if you find a good one let me know! - Sprite class: Kyra seems nice... now the HGE is opensource you may want to "steal" its sprite class. - debug code: MMGR locates memory leaks, a simple profiler will help you check performance (superpigs engenuity articles has one), use ASSERTS macros and such - Collision detection: there are many libs for that - XML and configuration files: for example tinyXML, SDL_config - Data structures and algorithms: of course use STL's vector/list/string but before you start implementing a datastructure or algo look for a ready one. - etc...
I recomend the following order:
1) setup SDL and openGL for 2d, draw a triangle, have a game loop, use keyboard to change color/zoom/angle 2) use SDL_image to load gif/jpg and use them as textures for polygons 3) use a GUI. make a secret debug panel(pops up when secret key pressed) in it you can print all sort of debug stuff, maybe get commands and act on them (for example: commands such as "load level.001", "insert sprite") 4) Make a sprite class, with animations (walk-left, walk-right). Delete the images and triangle from levels 1 and 2 and put a sprite that moves left and right as you press the keyboard. 5) You are ready for creating a game! Decide on the design (the more effort here the better) and read tutorials for the genre of the game.
