| |
Mixer
Registered: Apr 2008
Posts: 452 |
Drive access time
So, I want to read a random block from 1541 disk. Is it possible to make the access time somewhat constant or predictable? For example to make sure that the desired block or chunk of data can be loaded during the next second or shorter time.
Would the access time be any different if there is one huge data file which is optimized on disk for fastest reading?
Would such a loader/file system be compatible with other drives? |
|
... 9 posts hidden. Click here to view all posts....
|
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Oh, a large BITMAP scroller. You should have said that earlier, i was thinking of, well, scrolling text.
Quoting Mixerand obviously we pack the data to make things more complicated, just because hey Rather because the serial bus is the bottleneck. Highly packed data is preferred. =)
Quoting Mixerthe next data up/down/left/right is not necessarily on the other end of the disk Not only that, it's also ordered. Just that you have 2 axes instead of 1. So you'd maybe do something like divide a track in 2 (differently-sized) parts, one being the centre (visible part) and the other the surroundings in the 4 (or 8) directions. But better not overthink it... until running into actual problems. =) |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
The Ourobous-scrolller in The Elder Scrollers was all in bitmap, using a tricky AGSP-scheme, compressed data and predictable scrolling and I was almost out of bandwidth. So a random based scroller using bitmap will be a beast to code if possible at all or scroll very slowly. |
| |
Mixer
Registered: Apr 2008
Posts: 452 |
As you all know, using the repeat line-mode one can build a character set based bitmap, where every character line bitmap is from a different character bank, and the first character line defines the character pointers, which repeat over the rest of the screen. It works, but the timing is a bitch.
This is a very cool artificial mode, as one can change the bitmap gfx just by rewriting the top character line, and bank/char set every 8th line. To scroll up and down we allow the y-bitmap ptr to increment normally on one of the char lines, to get another set of repeatable characters, which then is the top line of the bottom screen.
The mode sees a 255 characters wide and 25 characters high bitmap, which can be addressed by writing only 80 characters on screen memory. 40 for the top row and 40 for the split row. And even that writing is only necessary when 8 pixels are scrolled to any direction. Most of the time, that mode only takes the 25 raster interrupts to manage the repeat-line and changing bank/char set.
So, one can show any screen sized rectangle on a 6 screens sized bitmap, without any memory copying.
Rest of the cycles are free for something else, such as loading stuff.
The amount of data to be loaded is about the same as with a bitmap mode gfx, but this version does not have to do any bitmap memory copying, so it might be a bit faster. All we need is to know what to load and where to.
Perhaps we should set up a programming compo to get this done? |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Ahh, scrolling through maps. That takes me back to working on Driv3r, where we had square tiles one or two hundred meters to a side full of instance data, and three sets of model data for the current and a couple of nearby neighbourhoods. Jeanette and I had to design a set of rules for the artists to stick to about how close together different neighbourhoods could be, given seek times on DVDs, and the time it took to load X many MB of models and textures..
IIRC the grid of instance data was just stored linearly on the disk, one row of tiles at a time. As long as the player car stayed below 88mph all was fine :D |
| |
Mixer
Registered: Apr 2008
Posts: 452 |
@ChristopherJam: Over 88 mph and -> future? |
| |
Pex Mahoney Tufvesson
Registered: Sep 2003
Posts: 52 |
ChristopherJam, that Reminds me of Crazy Taxi on Dreamcast when played from a downloaded and burned CD-RW when not adding empty files at the inner part of the disc. CDRom drives read slower on the inner tracks, and a copied Dreamcast disc would read too slow on the inner tracks. Fortunately, the collision map was already in memory, so the game ran fine, but the texture loading and 3d-models were loaded a couple of seconds too late when you were driving fast through the neighbourhoods, creating a lot of ugly pop-up effects. Filling the inner tracks with empty files solved the loading lag problem in that case! |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: As you all know, using the repeat line-mode one can build a character set based bitmap, where every character line bitmap is from a different character bank, and the first character line defines the character pointers, which repeat over the rest of the screen. It works, but the timing is a bitch.
This is a very cool artificial mode, as one can change the bitmap gfx just by rewriting the top character line, and bank/char set every 8th line. To scroll up and down we allow the y-bitmap ptr to increment normally on one of the char lines, to get another set of repeatable characters, which then is the top line of the bottom screen.
The mode sees a 255 characters wide and 25 characters high bitmap, which can be addressed by writing only 80 characters on screen memory. 40 for the top row and 40 for the split row. And even that writing is only necessary when 8 pixels are scrolled to any direction. Most of the time, that mode only takes the 25 raster interrupts to manage the repeat-line and changing bank/char set.
So, one can show any screen sized rectangle on a 6 screens sized bitmap, without any memory copying.
Rest of the cycles are free for something else, such as loading stuff.
The amount of data to be loaded is about the same as with a bitmap mode gfx, but this version does not have to do any bitmap memory copying, so it might be a bit faster. All we need is to know what to load and where to.
Perhaps we should set up a programming compo to get this done?
Yes ofc... but that is char mode still and very limited colors. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Quote:Reminds me of Crazy Taxi on Dreamcast
also sonic adventure and... the third game in the same engine :) |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Quote: @ChristopherJam: Over 88 mph and -> future?
The actual number we got back from "this many bytes per second and this many bytes per region with a tile size of X" was so very close to 88mph it would've been criminal not to round it ever so slightly :) |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Quoting Pex Mahoney TufvessonChristopherJam, that Reminds me of Crazy Taxi on Dreamcast when played from a downloaded and burned CD-RW when not adding empty files at the inner part of the disc...
Oh, nice. But yes, I think we did have to be a little careful about file placement on some of the Drivers. The same could well apply on c64 of course - some loaders will give you throughput dependent on which of the four speed zones you're in.
A slight clarification to my earlier comment btw - while driver 1 and 2 only had one "superregion" loaded at once (with long boring stretches between the neighbourhoods), Driv3r had three buffers to have up to three neighbourhoods loaded at once, with a three-colourable map of around a dozen or so neighbourhoods per city with no gaps between them.
Again, similar techniques could well be adapted to a c64 bitmap scroller, given that the tilesets are implemented entirely in software. |
| Previous - 1 | 2 - Next |
