Would you play a Mode 7 style racer?
Would you play a Mode 7 style racer?
I'm attempting to get a Mode 7 (Similar to F-Zero) rendering engine working on the CDi.
I've uploaded an early version:
http://www.rastersoft.net/project/
This is not fast enough for a game, but futher optimizations may help. Another option would be a fighting game similar to Ballz.
Currently I'm rendering every other pixel, and every other line.
I've uploaded an early version:
http://www.rastersoft.net/project/
This is not fast enough for a game, but futher optimizations may help. Another option would be a fighting game similar to Ballz.
Currently I'm rendering every other pixel, and every other line.
- Bas
- CDinteractive Admin
- Posts: 3041
- Joined: Mon Jun 20, 2005 11:14 am
- Location: the Netherlands
- Contact:
I would play anything that comes out on CD-i
A mode 7 style racer would be very cool although it sounds impossible in my ears on CD-i! This sounds like an excellent start of the year for CD-i!
Wow, I'm just looking at those screenshots and I'm amazed! Too bad I lend my CD-i player to a friend but if this can be realized on CD-i I'd be stunned!
Go for it!
Can you tell something more about it? How you got on the idea, how long you've worked on it, is multiplayer possible? Do you use the DVC capabilities?
A mode 7 style racer would be very cool although it sounds impossible in my ears on CD-i! This sounds like an excellent start of the year for CD-i!
Wow, I'm just looking at those screenshots and I'm amazed! Too bad I lend my CD-i player to a friend but if this can be realized on CD-i I'd be stunned!
Go for it!
Can you tell something more about it? How you got on the idea, how long you've worked on it, is multiplayer possible? Do you use the DVC capabilities?
Just posted on Black Moon about this news!
It's really amazing. The camera pans left, right and forward. Even at this early stage of development the movement is quite elegant. I'm guessing it doesn't need the DVC unless it's simply using the expanded memory that CD-i Emulator offers? I'll capture a movie as soon as I burn the ISO, that should give a good impression of how well this ticks! Great work Charles and do you really need to ask if we're interested in a Mode 7 style racer?
It's really amazing. The camera pans left, right and forward. Even at this early stage of development the movement is quite elegant. I'm guessing it doesn't need the DVC unless it's simply using the expanded memory that CD-i Emulator offers? I'll capture a movie as soon as I burn the ISO, that should give a good impression of how well this ticks! Great work Charles and do you really need to ask if we're interested in a Mode 7 style racer?
I wanted to try something a 'little more challenging' for the CDi, so I came up with the idea of trying to do a Mode 7 style racing game.Bas wrote:Can you tell something more about it? How you got on the idea, how long you've worked on it, is multiplayer possible? Do you use the DVC capabilities?
I've been working on it for about 3 week, in my 'limited' spare time over the holidays. I started with a C version running under windows, and optimized that with fixed point math and table lookups. I then converted it to x86 assembly language, and moved it over to the FM Towns.
The next version was the X68000 version, since it used a 68000 and was easy to debug using MESS (http://www.mess.org). The X68000 version was then ported to the CDi.
Yep multiplayer, using half of the screen for each player, should be possible. It would be slightly slower than a single player version, but futher optimization will help with that.
No, there's no need for the DVC. The graphic tiles, for this version, take up 56k, and the course map takes up 16k, which will be reduced to 8k shortly. There is still plenty of memory for compiled game sprites and a scrolling background.
Yep, no need for the DVC. I might be able to use it to preload more of the data, if it's available or something.Devin wrote:I'm guessing it doesn't need the DVC unless it's simply using the expanded memory that CD-i Emulator offers?
I was going to ask about Sprites and a Backdrop but it sounds like this is in capable hands!cdoty wrote:Yep multiplayer, using half of the screen for each player, should be possible. It would be slightly slower than a single player version, but futher optimization will help with that.
No, there's no need for the DVC. The graphic tiles, for this version, take up 56k, and the course map takes up 16k, which will be reduced to 8k shortly. There is still plenty of memory for compiled game sprites and a scrolling background.
Will it be possible to eliminate the need for alternate scan lines or is that a necessary evil to make this work?
Also here's a small movie in ASF format of the demo in action...
Mode-7 Demo
It's an attempt to lighten the load on the cpu. It only has to do half of the work each time.Devin wrote:Will it be possible to eliminate the need for alternate scan lines or is that a necessary evil to make this work?
[/url]
It shouldn't be alternating though. it should be consistently only drawing every other line (and every other pixel).
- cdifan
- CD-i Emulator Author
- Posts: 923
- Joined: Fri Jun 24, 2005 6:19 am
- Location: The Netherlands
- Contact:
Some technical tips...
By playing with the pixel repeat counts and display line start addresses, you can get the video hardware to double the memory pixels both horizontally and vertically, effectively reducing the screen resolution by a factor of two for the area.
That would eliminate the "black" space between pixels and might even allow more efficient drawing as two pixels would fit in one 16-bit word which can be written in a single bus cycle; as it is now they require two bus cycles because they are split over two 16-bit words. It would also reduce the memory requirements by four (not that this is really needed, of course).
If you have DVC memory, by all means put your code and data in it because it is significantly faster and would thus allow a higher rendering frame rate (I assume that your're not rendering at the display frame rate of 50 or 60 Hz). Video memory should only be used for the actual screen buffers in this case and the number of accesses should be minimized (always a good idea anyway).
By playing with the pixel repeat counts and display line start addresses, you can get the video hardware to double the memory pixels both horizontally and vertically, effectively reducing the screen resolution by a factor of two for the area.
That would eliminate the "black" space between pixels and might even allow more efficient drawing as two pixels would fit in one 16-bit word which can be written in a single bus cycle; as it is now they require two bus cycles because they are split over two 16-bit words. It would also reduce the memory requirements by four (not that this is really needed, of course).
If you have DVC memory, by all means put your code and data in it because it is significantly faster and would thus allow a higher rendering frame rate (I assume that your're not rendering at the display frame rate of 50 or 60 Hz). Video memory should only be used for the actual screen buffers in this case and the number of accesses should be minimized (always a good idea anyway).
Before I tried horiz. doubling the pixels, and it looked odd. Maybe doubling in both directions wouldn't looks as bad.cdifan wrote:By playing with the pixel repeat counts and display line start addresses, you can get the video hardware to double the memory pixels both horizontally and vertically, effectively reducing the screen resolution by a factor of two for the area.
I'm an optimization or two away from calculating 2 or 4 pixels in a single loop. I'm looking to eliminate 4 fixed points multiplies per scan line first. I'm investigating the smallest lookup table I can get away with.cdifan wrote:That would eliminate the "black" space between pixels and might even allow more efficient drawing as two pixels would fit in one 16-bit word which can be written in a single bus cycle; as it is now they require two bus cycles because they are split over two 16-bit words. It would also reduce the memory requirements by four (not that this is really needed, of course).
It's not close to 50 or 60 hz yet. How much faster could I expect DVC memory to be?cdifan wrote:If you have DVC memory, by all means put your code and data in it because it is significantly faster and would thus allow a higher rendering frame rate (I assume that your're not rendering at the display frame rate of 50 or 60 Hz). Video memory should only be used for the actual screen buffers in this case and the number of accesses should be minimized (always a good idea anyway).
Unfortunately, due to using a tile map, transfers to video memory are probably the fastest part of the inner loop. It currently has to get the tile number, and then get the pixel within the tile. Currently this is a series of asl/asr or ands. I could go with a bitmap landscape, but that would push memory requirements through the roof. That's 1MB for the 1024x1024 map I am currently using, compared to less than 128k now.
Hi everyone
This demo looks amazing and I'm really excited by this game. CD-i is crying out for a racing game - especially after the disappointment of missing out with ''Dead End''.
Cd-i is still going strong in 2008 - 10 years after Philips released their last game for our system.
Charles, Devin, Bas & everyone - KEEP UP THE GREAT WORK!
All the best,
Alan
This demo looks amazing and I'm really excited by this game. CD-i is crying out for a racing game - especially after the disappointment of missing out with ''Dead End''.
Cd-i is still going strong in 2008 - 10 years after Philips released their last game for our system.
Charles, Devin, Bas & everyone - KEEP UP THE GREAT WORK!
All the best,
Alan