Jump to content
  • Advertisement
  • entries
    383
  • comments
    1075
  • views
    354068

Learning my A B Cs

Sign in to follow this  
Trapper Zoid

91 views

Random Thought for the Day
Next-gen console argument wars have been on the rise on the last few months. I find it weird that some people argue over choices of consoles with a greater fervour than politics or religion. Although I can understand the need to crush those heretics who think Nintendo is just for kids [grin].


Text System

...although it's pretty close. I've got a prototype font made from my own handwriting that looks a bit slapdash but is suitable for debugging and prototyping. The text system now supports single lines of text scaled to different widths and heights. At present coloured fonts and any justification other than left is not supported, but those additions are pretty easy to add. It also doesn't support multiple lines of text (without using more than one text object), but I'm not sure whether I'll need that functionality for Ice Slider. The interface is also very clumsy due to its creation as I added on each individual feature, but I'll wait until I get a good idea of how I want to use the text within the game before I rework that.

One thing I've noticed when browsing the OpenGL forum here for tips is there's a big warning against using OpenGL immediate mode. At present due to my limited knowledge of OpenGL I'm using immediate mode for my sprite rendering, and I'm not sure if this will end up crippling the graphics system if the internal design depends on it too much. I don't know that much about vertex buffers or lists, and frankly I'm not sure if I need to know about them; given my engine is 2D all I'm wanting to use OpenGL for is textured quads, occasionally with some colour or alpha effects. Given I'm not using any complex geometry (just quads) I doubt I need to worry that much, and I'm certainly not going to deal with performance issue now. But I would be interested in knowing how well OpenGL deals with sprite quads in immediate mode. I doubt I'll need to render more that 10,000 sprites at any one time (and that's probably an overestimate), so I'll rig up some sort of test case in the near future to see if that would be a problem. I hope that vibe I'm getting from the forum is just down to the tendency of programmers to overly chase high framerates.

Controlling the Input
The next big system I need to add is input/control so I can start doing stuff with the engine. I'm using SDL, so this shouldn't be too difficult. The main choice is the paradigm I use for communicating the input to the main part of the program. There's several ways to go about this:

  • Have the Input class act like a big data structure, and let game objects read which buttons are being pressed as part of their update cycle. This approach is pretty easy to implement, but the resulting system could get messy; every object is in charge of managing its own input.
  • Have game objects register an input reading function with an Input manager. This is similar to the first approach but gives more control to the input manager about what receives input. Would be easier to switch input for objects on and off.
  • Store a function pointer for each key which is called upon a key press. Most keys map to a null function that does nothing. This is a pretty neat approach, although it makes it hard to assign multiple functions to a single key or to allow combinations of key presses.

I'll figure out what I like the best and roughly plan how the system works, but I'd be interested if anyone has any recommendations. I'm sure there's many approaches I haven't listed too (this is all just off the top of my head).
Sign in to follow this  


5 Comments


Recommended Comments

If you're using OGL for 2D stuff (we do for A22), I would highly recommend using display lists to render everything, it makes a huge difference when you start rendering huge numbers of quads (like for particle effects).

Let me know if you have any questions, because I'm getting pretty knowlegable after 6 months of development on A22[grin]

Share this comment


Link to comment
How much of a difference does it make?

I'm hoping it isn't too much of a hassle to implement though. I'd still really like to be able to just call a "DrawSprite" function call in each game object that needs to be displayed. As long as I can keep the interface the same I'd be happy; I just don't want to have to do a bunch of weird things within the game itself that makes development a chore.

Of course, this'll all wait until the first reworking of the engine. Priority #1 is getting the game running. Since Ice Slider won't have any particle effects I doubt it will make much of a difference!

Edit: No, wait: I was planning on putting falling snowflakes in there. I guess that counts as a particle effect.

Share this comment


Link to comment
Well, in Angels 22 it made a bit of a difference because we do a whole lot of alpha and transparency tricks in the game whcih, coupled with tons of physics and AI calculations taking place, really slowed up the game.

I'm not quite up to date on what you want Ice Slider to be, but unless you're going for something relatively complex, immediate mode should work fine, but keep in mind that you will eventually have to learn the more advanced stuff, and display lists are probably the simplest ones.

Share this comment


Link to comment
Ice Slider will be a pretty simple tile-based puzzle game, so I don't think it requires much in terms of graphical power. I'm hoping to make it look a bit like a higher-res SNES game.

I suppose my main concern is I don't really want to get too bogged down with speed issues, since I'm not really that interested in mastering OpenGL. As long as I can get it to spew out pretty looking rectangles at a decent rate then that's fine by me.

But I'll put looking at vertex lists on my "list of things to do in the second revision".

Share this comment


Link to comment
OpenGL immediate mode shouldn't really affect you drawing sprites -- you'll need to be up to a 3D-class application to gain really obvious benefits from vertex buffers. Glow still uses immediate mode for rendering the sprites and particles.

I did do display lists for the "3D" tiles in Glow; you might want to try this if you keep drawing complex geometry over and over, or build a display list for tiles in general.

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!