Castle Paradox

[phyrfox]

Alright. Here's this week's updates.

Progress is moving. Working 11 hours a day means I can only spend weekend days to seriously program, the rest of the time is just an hour here and an hour there. So, what has been accomplished this week?

Research on SDL and various other things have occupied a portion of time, debugging a few elusive glitches a bit more time, and the rest creating structures and code to manipulate these structures. Actual engine does not do anything yet, but that will be easy to implement when I know all is well with memory control.

Roughly 700 lines of code exist at the time of this posting (should be over 1000 or so by the time I retire tonight); most of this code are structures and things that will be used. A RPG-loading routine is in the works in two parts: one to load an entire RPG, and one just to index an RPG so it can be indexed with file pointers. Now to make the rest of the structures need to be implemented so they can be handled in memory.

Here comes the tricky part; I'm still debating between loading the entire file into RAM, or just using a load-on-demand feature. Load-on-demand can be implemented with my current code; the only difference between the two is that the file in RAM would be read faster. Either way, there's going to be a set amount of memory for "in-use" structures. I would guess that in-use structures will probably require around 1-2MB, so the primary question here is "speed versus memory usage." I think I'm going to write a bunch of load-on-demand functions that can be plugged into either a file or RAM buffer, thus it will be accessable which mode is used in the menu system.

~= phyrfox =~

[jabbercat]

These days most people don't use anything under a P3, so surely a read-on-demand couldn't be that CPU intensive. It depends wether it treats the file like a stream or not.

[phyrfox]

[jabbercat]

fread and fwrite? Don't you like streams?

I can't see any problem using the same method that the OHR uses for reading the lump. Ofcourse one way to get around that problem is placing the temp folder in the same folder as the engine. That should sort it, right?

Out of interest, what compiler are you using?

[phyrfox]

[jabbercat]

Watch-out compiling SDL_Audio with MinGW, you can get all sorts of errors.

Are you implementing OGL with the engine?

[phyrfox]

[jabbercat]

I was thinking that you could use verticies with use the attack graphics as a texture and then do nice rotating and semi-transparet effects with them.

Embedded OGL with SDL is supported.

[Rinku]

"These days most people don't use anything under a P3, so surely a read-on-demand couldn't be that CPU intensive. It depends wether it treats the file like a stream or not."

while true this isn't a good argument. here's a story to illustrate:

you have 5 best friends who visit you. 1 of them is in a wheelchair. when deciding how to construct your new house, should you build a wheelchair ramp, or say 'most of my friends have legs, therefore i don't need to build it'.

it's the same issue here. sure, most people have lots of ram. i have 56mb. some ohr users, and some people who play or will play our ohr games, have less. being able to play a game with low ram is to us like a wheelchair ramp: sure, you can save time by not building it, but if a little extra effort allows everyone to be able to use it, then it's good to do it.
_________________
Tower Defense Game

[jabbercat]

I hate to say it, but Rinku-chan makes sence.

I'm sure optimization can be done to get read-on-demand running smoothy though. Using registers in loops is a good start.

[NeoTA]

phyrfox:
disk caching on windows should allow you to use at least 2mb of on-disk data at a time with impunity.
on linux.. it will cache the entire thing if possible!.

Have you benchmarked!?