Maarten ter Huurne schrieb:
At 11:13 PM 02/27/99 +0100, you wrote:
The game I am speaking about is: OSR (One Shot Rising).
I remember playing it at a fair.
Because there were no enemies in it, it was rather difficult to image what
it is supposed to play like.
I know why I doesn't ask for your opinion (at least - till now...)
The game is designed in screen 4
That would leave a lot of free VRAM, doesn't it?
You could put level data there. Like Cas said, you'll only have to fetch a
small number of bytes per interrupt.
The scroll needs between 96 and 800 Bytes per interrupt...
Another option is to put MWM/MBM music in VRAM. I don't know of anyone who
ever did this, but it would make sense. MoonBlaster replayers work like
this: they fetch crunched data from the song file, decrunch to a buffer and
then play from that buffer. If you put the crunched data in VRAM, that
would hardly slow things down.
This idea sounds very interesting!
My conclusion is that there are some things you should try first, before
moving to higher system requirements.
My target was (and is): a game programmed in '86 standard.
One argument: one of our designers has a not-modified MSX2...
(with use of additional hardware if connected)
How come you are in memory problems anyway? Could you give a summary of
which components take up how many memory?
I think I solved them - let's c what about the speed...
Data I have to store (with approx. byte-size)
real vram-data:14.976
various vram: 98.304 (where are the darn enemys... ;P )
level: 49.152 (Levelsize = 64 screens)
animation+
objectinfo:32.768
code: 16.000 ?
kernel-code:5.000 ?
musicdata: ?
Yes, MoonSound SFX! []
But I will also try to make sfx on psg/fm/audio...
greetz'n'hope the best
chief
--
Tilburg Team: Janosch, SGI, D-AX, inDark,
-===- Maspo, SFS, Chief-Gavaman
MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put
in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the
quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
