Cannonball on 32X ?

Ask anything your want about the 32X Mushroom programming.

Moderator: BigEvilCorporation

Post Reply
djcouchycouch
Very interested
Posts: 710
Joined: Sat Feb 18, 2012 2:44 am

Cannonball on 32X ?

Post by djcouchycouch » Wed Jan 23, 2013 2:03 pm

Have you guys seen the Cannonball project?

http://reassembler.blogspot.ca/p/cannon ... ngine.html

Any idea if it could be ported to 32X or it's totally the wrong approach?

Moon-Watcher
Very interested
Posts: 117
Joined: Sun Jan 02, 2011 9:14 pm
Contact:

Post by Moon-Watcher » Wed Jan 23, 2013 2:43 pm

Can't say if it is possible or not but it's really cool idea

ammianus
Very interested
Posts: 124
Joined: Sun Jan 29, 2012 2:10 pm
Location: North America
Contact:

Post by ammianus » Wed Jan 23, 2013 6:21 pm

I wouldn't rule it out per se but some facts from looking at the page and the github source

1) The port is written in C++, to my limited, knowledge 32X may be too slow to handle C++. Sega docs even say only ASM, C supported.

2) The port appears to use libSDL, which itself would need to be ported to 32X or you would need to rewrite the basic graphic rendering functions that they are using yourself since there isn't any "out of the box" sprite-based graphics library on 32X.

Lets say you get over the port coding challenges, there is the question of whether the hardware requirements can be handled by 32X (+MD):

Out run specs:
http://www.system16.com/hardware.php?id=697
Main CPU : 2 x MC68000 @ 12.5 MHz
Sound CPU : Z80 @ 4 MHz
Sound chip : YM2151 @ 4 MHz & SegaPCM @ 15.625 kHz
Video resolution : 320 x 224
Board composition : CPU board + Video board
Hardware Features : 128 Sprites on screen at one time, 2 tile layers, 1 text layer, 1 sprite layer with hardware sprite zooming, 1 road layer, can draw 2 roads at once, translucent shadows
So 32X lacks the hard ware zooming or the concept of "layers", so whatever you draw would have to fit in the RAM uncompressed. Might be good to know how big those sprites are. In theory our two "fast and furious" SH2s should be able to do what these are being used for "2 x MC68000 @ 12.5 MHz"

Might also depend on how creative you can be to incorporate the MD hardware in the game as well, maybe to do some of the layers of road in MD while 32X does the sprites?

Chilly Willy
Very interested
Posts: 2984
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Wed Jan 23, 2013 6:47 pm

A straight port of the program would not be possible. It uses WAY too much ram, and the way the graphics are done would be incredibly slow. I looked at an N64 port, and this would probably be right on the edge of what the N64 could handle. It would need a complete rewrite for the 32X.

As to C++ - modern gcc c++ is pretty fast, and I have gotten c++ working on the 32X. The primary issue with c++ is memory usage - GC encourages programmers to waste memory like no one's business. It was easy to bloat a simple TicTacToe demo c++ app on the 32X... when using c++ on old consoles, you need to take direct control over all the resources for the best speed and efficiency.

This is yet another example of PC programmers relying on the "infinite" power and memory of current PCs. This one isn't as bad as some, though.

ammianus
Very interested
Posts: 124
Joined: Sun Jan 29, 2012 2:10 pm
Location: North America
Contact:

Post by ammianus » Wed Jan 23, 2013 7:34 pm

I was wondering about this after learning about CPS-2 architecture. Have you tried directly reading sprite graphics from ROM and copying it to Framebuffer without writing it to RAM? I assume that would be really slow, but I haven't tried that before, it might be one way to save some RAM.

The other thing I was thinking of was using unused space in the Framebuffers themselves to store data which you would then copy around as needed?

Chilly Willy
Very interested
Posts: 2984
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Wed Jan 23, 2013 9:05 pm

ammianus wrote:I was wondering about this after learning about CPS-2 architecture. Have you tried directly reading sprite graphics from ROM and copying it to Framebuffer without writing it to RAM? I assume that would be really slow, but I haven't tried that before, it might be one way to save some RAM.

The other thing I was thinking of was using unused space in the Framebuffers themselves to store data which you would then copy around as needed?
The entire graphics handling just needs to be completely rewritten. The way the graphics are handled now doesn't need too much ram, but would be very slow as it's done one layer at a time, with multiple calls to each layer with a different priority. Most of the ram usage in the gfx right now has to deal with how the road/sprite data is pre-processed. That could be done beforehand and put in rom.

Charles MacDonald
Very interested
Posts: 292
Joined: Sat Apr 21, 2007 1:14 am

Post by Charles MacDonald » Thu Jan 24, 2013 2:24 am

I think it's definitely possible, Afterburner and Space Harrier run on almost identical arcade hardware and faithful ports were made for the 32X. Probably some animation sprites were dropped or very large sprites were shrunk down a bit to work in memory constraints.

In all of these arcade games the second 68000 was used to control the road layer exclusively. Everything relating to sprites was handled by the first 68000. Given how slow communication was (the main CPU can access the second CPU's RAM by stalling it; communication is one-way) it seems unlikely the second 68000 would get many other game tasks to perform.

I agree that it would probably take a lot of rewriting to make it work effectively on the 32X, and a straight port would probably have poor performance.

ob1
Very interested
Posts: 463
Joined: Wed Dec 06, 2006 9:01 am
Location: Aix-en-Provence, France

Post by ob1 » Thu Jan 24, 2013 9:46 am

Well, there are obviously some other constraints :
Hardware Features : 128 Sprites on screen at one time, 2 tile layers, 1 text layer, 1 sprite layer with hardware sprite zooming, 1 road layer, can draw 2 roads at once, translucent shadows
But the goold ol' mushroom does have some horsepower ;)

mic_
Very interested
Posts: 265
Joined: Tue Aug 12, 2008 12:26 pm
Location: Sweden
Contact:

Post by mic_ » Fri Jan 25, 2013 6:31 pm

The primary issue with c++ is memory usage - GC encourages programmers to waste memory like no one's business.
C++ isn't garbage collected, though. At least not if one is talking about implicit GC as a standard feature of the language (like in Java). C++ compiler vendors are allowed to add a GC (and the way it should behave was formalized in C++11) but it's not a mandatory feature - e.g. GCC does not have one AFAIK.

There are ways to do explicit GC in C++, however, e.g. the shared_ptr functionality added in C++11.

Overall, use of C++ should not affect the performance or memory usage that much. Excessive use of virtual methods, especially in combination with multiple inheritence, should probably be avoided since it can end up creating relatively large vtables.
RTTI is also a good idea to avoid unless you absolutely need it, both for the memory cost and the performance cost of e.g. a dynamic_cast. Exception handling is another feature that is a good idea to disable unless you really need it.

Chilly Willy
Very interested
Posts: 2984
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Fri Jan 25, 2013 9:14 pm

mic_ wrote:Overall, use of C++ should not affect the performance or memory usage that much. Excessive use of virtual methods, especially in combination with multiple inheritence, should probably be avoided since it can end up creating relatively large vtables.
Good point.
RTTI is also a good idea to avoid unless you absolutely need it, both for the memory cost and the performance cost of e.g. a dynamic_cast. Exception handling is another feature that is a good idea to disable unless you really need it.
Yeah, I use "-fno-exceptions -fno-rtti" on C++ compiles most of the time. It's especially big for small consoles. Also avoid iostream on small consoles - it bloats the program like no one's business. It made my ~50KB c++ example about ~500KB on the MD/32X. :)

ammianus
Very interested
Posts: 124
Joined: Sun Jan 29, 2012 2:10 pm
Location: North America
Contact:

Post by ammianus » Sat Jan 26, 2013 12:50 pm

Charles MacDonald wrote:I think it's definitely possible, Afterburner and Space Harrier run on almost identical arcade hardware and faithful ports were made for the 32X. Probably some animation sprites were dropped or very large sprites were shrunk down a bit to work in memory constraints.
I read somewhere that the 32X version of Afterburner had framerate of 30fps, but the arcade was 60fps is that correct?

The arcade version does seem to have better, more crisp looking sprites, from my unscientific youtube research.

Still pretty impressive what they did.

Post Reply