Unlump only runtime-modifyable lumps

[ohrrpgce-bugbot]

[bz#92]

To minimize unlumped size:

1. save a 'table of contents' file, which consists of pairs (filename, absolute
   offset into .RPG)
2. when opening a lump, first try to load it from the unlumped-stuff-directory
3. Otherwise look it up in the TOC , seek to the stored offset in the RPG file,
   and read it from there.

a list of modifyable lumps follows:
* DT1 (enemy data)

Foemap needs to be unlumped, since it is accessed every step.
Anything else?

From: @0ion9
Severity: feature request

[ohrrpgce-bugbot]

Comment author: @0ion9

.. and HS, since it's lumped itself.

[ohrrpgce-bugbot]

Comment author: @pkmnfrk

Um, why? I don't think the speed benefit gained from reducing the load time is
all that important. This would increase the time it takes to open a lump, even
if by only a little bit. However, a little bit adds up...

In short, if there is a benefit, by all means. However, I don't see any.

[ohrrpgce-bugbot]

Comment author: @rversteegen

You mean that lumps are only unlumped when they are needed, then the single lump
is read from the RPG file, copied out, and read normally? Of course it isn't
possible, without painful modification of many assembly routines and QB
functions, to read straight from the .RPG file.

The problem is, you have have to wrap dozens upon dozens of function calls.
Easiest way to do this would appear to be replacing "lumpname.ext" with
lump$("lumpname.ext") which returns its input, checks if the file exists,
unlumps if not.

But, is it really useful? The idea of unlumping at the beginning is so as to not
get lags during play.

[ohrrpgce-bugbot]

Comment author: @0ion9

The purpose is to minimize space usage, as i said: if you have a 32mb RPG,
unlumping it brings the space used to double that.
I actually meant no unlumping at all would occur for the majority of lumps: the
unlumper would return a filehandle pointing at the start of the lump and reading
the lump would proceed from there.

[ohrrpgce-bugbot]

Comment author: @rversteegen

The problem, like I said, is that most binary lumps are loaded with either
XBLOAD or assembly routines like loadsprite. They don't take file handles as
arguments, but filenames. Anything which isn't read like this tends to be a tiny
text lump.
You would have to modify dozens of functions to load data in a new way.

[ohrrpgce-bugbot]

Comment author: @bob-the-hamster

This would almost certainly severely damage memory usage (because of code-bloat
from the wrapper functions and new code neccisary to read various lump types
directly from the RPG file)

Disk space is cheap, but that 640k is a painful limitation.

Of course, I still do feel sympathy for those who must suffer with limited disk
space. I remember well my first computer with it's 80 megabyte hard drive. I
would have been able to install and play about ONE large OHR game on it :P

Unless we can think of a very memory-efficent way to do this, I am afraid I'm
gonna have to veto the idea :(

(Naturally source ports and re-implementations can take this approach with no
problems.)

[ohrrpgce-bugbot]

Comment author: @pkmnfrk

COme on Neo, don't tell me you don't have enough space to play Sword of Jade!

Really, 64 Megs is nothing on any computer made since... 1999.

Marking this as Won't Fix, as per James' veto.

[ohrrpgce-bugbot]

Comment author: @rversteegen

This idea was canned because we didn't have the FreeBASIC port back in 2005. These days, the only substantial advantage of the current scheme over Neo's suggestion is that it already implemented, so I am renominating it.

[ohrrpgce-bugbot]

Comment author: @bob-the-hamster

Actually, IIRC, the only runtime modifiable lumps are the enemy formations and the enemy stats. Those already get duplicated to a temporary location (effectively double-unlumped)