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

Monday update time

Sign in to follow this  
Trapper Zoid

117 views

Random thought for the day
Maybe you can help me interpret this dream I had. I was standing in a European-style twisty city lane in the market district. I was examining a shop's collection of brightly coloured hand-woven woolen baskets in the shape of Platonic solids. Beside me some random guy was explaining his theory that since all great philosophy came from China, technically no non-Chinese knowledge can be said to exist. Across on the other side of the lane in a shop-front window was a chalk board upon which was written "Hi, I'm the Great God Eric. Ask Me About Eggs!".

Not sure what any of that meant, but I have a suspicion it's got something to do with the Lounge.


Progress Update

I didn't get as much done as I'd hoped over the weekend. Last week I'd hoped to get a font system up and running, but unfortunately due to some mild illness and lack of decent sleep (possible cause of that random thought of the day) I've been more spaced out than usual, which tends to lead to my train of thought wandering off when I'm coding. It's hard to stay productive if every five minutes you forget why you're looking at this particular screen of code. I'm also a bit behind in my music for Blocky Man, having not written anything I've been that happy with since last weekend, darnit.

But what I have done is finish off the basic functionality of my graphical resource manager class, the code to load in and store texture information for use as 2D sprites. That's been a pain and a half to finish off, as writing resource handling routines is considerable less fun than a trip to the dentist (well, at least my dentist, who's quite likable even when he's ripping out teeth). It's a bit shaky in places due to me making up the design on the fly and there's probably some nastiness in there that I'll have to deal with in a later revision of the code base, but thankfully most of that is internal to the class so the rest of the game doesn't need to know about the lurking horrors that lie within.

Overview of Graphics Resource Manager for PE-1 (Penguin Engine Mark 1)

Here's a brief overview of what the system does as it stands. There's still a few tweaks that need to be done but this is pretty much what I think I'll stick with for PE-1 (Penguin Engine Mark 1). Once Ice Slider (the game I'm presently working on and the test for PE-1) is finished I'll probably rewrite most of this for PE-2, but I think it'll be workable as a first draft.




These are just some sample images I'm using for my first few tests. I'm still using Inkscape SVG files as the basis of all my art. However since SVG is a bit troublesome to directly use in a game for PE-1 I'm exporting the files to PNG in Inkscape (upgrading to SVG as the basis of raw art is a task for PE-2, the next major rework of the engine).

The game reads in which files to open using a handy XML file:









This file format is a bit out of date: I don't really need those "imagefiles" and "imagecodes" tags, as I'm now storing the image codes in a different XML file. I probably also don't need the XML document header either as this is just an internal config file.

Currently I'm only supporting PNG files, but each file has an XML file associated with it telling the dimensions of the sprites contained within it. For example, the "circletest" image has a circle and a triangle specified by the following XML file:






The really nifty thing about this is that the "rect" tags specifying the sprite positions are in exactly the same form as the "rect" tag used in SVG. So what I do is keep the SVG raw data file in the same directory as the PNG file. If the game is compiled in debug mode and it detects the SVG file there, it reads the first layer in my Inkscape SVG format which I've dedicated specifically to invisible rectangle defining the sprite positions. It then strips out all the rects, rounds the measurements to the nearest integer and writes them in their own XML file. So I don't need to figure out the values of this file myself or make my own sprite definition tool, it's constructed for me directly from my art data all done within Inkscape. All I need to do is remove the SVG file in the final release version. It's all really neat, and makes me look forward to when I'll try to use SVG itself as the main data format.

For accessing the files themselves, I've decided to use unique integer codes specified in an enum in a header, at least for PE-1. I'm a bit uneasy about this, as it means there's a bit of coupling between the game code and the engine code which I probably should do without - the engine code will recompile in part when this file is changed. There's also the problem that everything that needs image code will recompile if I modify this header file. But it's simple and easy to get going, so that's what I'll try for the Mark 1.

Here's the header file and a corresponding XML file:

enum IMAGE_CODES {
NULL_IMAGE, // not to be used
CIRCLE,
TRIANGLE,
SQUARE,
STAR,
NUM_IMAGE_CODES };








This reminds me: I have to change the header file so there's a prefix upon all those image code enums: it really should be "IC_CIRCLE" and "IC_TRIANGLE" to avoid any future nastiness and clashes.

Anyway, the XML file is used to translate the ids in the sprite definition "rects" to the appropriate number. This file, like the rect files themselves, is generated from the header file to ensure the values match. So as long as I name the rectangles in my Inkscape file the same as their corresponding enum value, the system should automatically link them up on run time.

So as it stands, I've got the basics pretty much down. As far as I know, I can get these test images from files to OpenGL textures reasonably cleanly. I say "as far as I know" as I haven't yet done the final step - displaying the darn shapes on the screen. I'm up to the bit in the design where I have to make decisions about how to interface the resource manager with the rest of the graphics module to display sprites on the screen. What interface do I want to display sprites? What co-ordinate system should I use for the screen? What length should I define the screen to be to make it resolution independant? Should I make the origin at the top-left of the screen or the centre? Once I've decided that, I need to write the graphics routines, plug everything in, and hope it works! Hopefully I can the text system up and working by the end of next weekend then.

Any questions or suggestions from those of you with a better idea of solid engine design?
Sign in to follow this  


4 Comments


Recommended Comments

I had a really productive weekend myself -- I bet you really wanted to hear that, eh? ;)

One reason for my sudden jump in productivity (after months and month of nothing) is that I decided to stop fretting about design issues. Oh, you don't like my global variables? BITE ME! I know that my code is not going to be pretty or professional, but I've decided to code things up and get them going and worry about efficiency and design later. None of the projects I'm working on at the moment are very big, so design guffs shouldn't really prevent me from getting them to work. So I'm just getting stuff to work and I'll think more about the design and how things worked in the post-mortem. I think this would be a poor way to approach a large project, but for now I just want to get a few games under my belt and chalk up some experience.

Does that apply to you? I have no idea.

Share this comment


Link to comment
Can't help much, but I'm certainly interested in implementing SVG in my own game engine. It seems very useful for game UI and is much much much cheaper than buying the tools to work with gameswf.

BTW, we should have a conversation about engine design and motivation one of these days. Give me a PM with your IM details and I'll try to coordinate with your craaaazy time zone.

Share this comment


Link to comment
Quote:
Original post by johnhattan
My question is "why are you rewriting Flash?"

Because I want to? [smile]

Admittedly I've noticed the similarities. I really should give Flash a go sometime soon to see if it's worth a purchase. I still think it's worth while writing my own system purely for the experience value though; I'd like to get better at my C++ coding.

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!