Well, I don't think it really matters. I personally like to write my rendering stuff first, but thats mainly because I like graphics programming

--TheGoop

I agree with Dragon. I always write my file reading code before my drawing code.

------------------
http://qoy.tripod.com

If you're writing an engine, it is generally a much better idea to do the core glue code (like file handling, as mentioned in this case) first and then do the rendering afterwards, than to do the opposite. Any programmer that considers not doing the graphics stuff first as "backwards" hasn't written enough code to know better.

The fact is, it's not backwards at all. Writing the renderer first is fine if you just want to play with graphics code, but if you want to make a larger-scale engine, then it makes little architectural sense. The graphics side of an engine is just the visual "front end" to what's going on underneath, so by building everything around the renderer you're tying the engine into that representation, and that kind of thing will only hurt you later.

Don't worry Dragon, it's not reversed at all.

The only problem I would find with that is "seeing" if it worked. It would be back to get all that code done then to see it rendered incorrectly. Where's the problem? Was it in the loading? The rendering?

I'm writing an engine here and instead of writing core rendering function of the engine, I'm starting on the map loading stuff and then working that way up. Several "programmers" called that method "a fucked up approach". Any comments?

my style:

map file -> map structure -> map rendering

[This message has been edited by Ðragun (edited December 11, 1999).]

I believe the official term is "top-down design"

I'd just include a version number in the file header and actually use it in the load routines if I were you.

And stop talking to programmers, talk to system engineers