Quantcast
Channel: Interactive Dreams
Viewing all articles
Browse latest Browse all 1857

[Developers talk] When you develop CD-i homebrew and test it on CD-i Emulator and real CD-i hardware, is the speed the same or does real CD-i hardware suffer from loading times?

$
0
0


CD-i member TwBurn is developing a new CD-i homebrew game called 'Nobelia' on CD-i and he developed it mainly by testing it on CD-i Emulator. Now that he has released the first demo version v0.1, he has more experience of the game being tested on different kind of real CD-i hardware. How does Nobelia perform on a CD-i player? TwBurn: "It worked quite well, load times are a lot higher, and the cursor in the emulator (or at least the bios I'm using) wraps around and my own player does not, so I'm running into invisible walls, but that should be easy enough to fix". The funny thing is CD-i Emulator emulates the actual disc speed okay. It just doesn't have any seek delays. "I haven't timed it, but it did feel longer. On the emulator I know what time I get the screen. And I should probably clear the screen first, now you get garbage for quite a bit. Its mainly an issue for the loading at start when I load the tileset and title image. Level loading is fast enough, but that one is less than 1k of memory."

CD-i member cdifan has an idea where this comes from and he shares in this technical talk some ways how to improve on memory usage during CD-i development: "Using the command 'fread' to load probably is part of the problem, it buffers internally so instead of a single large I$Read operation you get multiple small ones, incurring a seek delay on each one. If you do a single large read() call it will be one I$Read which should be a single disc operation (if you have the seek position and read size both multiples of 2KB). You would need to size your buffers large enough for that.

It's better to set up the CIL and stream it into memory with ss_play. Build one with all the data chunks you need, set up the CIL correctly and off you go in a single disc operation. You'll need a separate PCB for each chunk, you can either link them together with each having the exact (padded) buffer size of that chunk and put them all after each other in a single channel, ot you can put each PCB on a separate CIL entry and use different channels. 

You'd really want to use non-realtime data sectors, otherwise they will not use EDC/ECC error correction on correctable disc errors, but I think master does not support that (we used to "patch" such RTF files after them having been created separately). vcdmastr might, though, it's not an issue until you actually burn/press a disc for distribution/replication. There are also ways using only two PCB's and real-time adjust their sizes and pointers while playing the RTF, but it's really not worth it in my opinion. PCB's are not big... If you want to get really smart, you could allocate a PCB into one of the still-to-be-loaded blocks for no net memory cost."

Nobelia on CD-i is currently efficient enough on memory usage at the moment, so it is not needed to go to those lengths. But, as cdifan sais, wringing the absolute last bit of performance out of the system used to be a habit. Every additional KB of memory used to mean some more sprite frames or a sound effect improving game quality on CD-i! 

 [Thanks, cdifan, TwBurn]


Viewing all articles
Browse latest Browse all 1857

Trending Articles