SpritesMind.Net

commodorejohn wrote:There's one thing I have to say about this whole idea:

Quake 32X CD.

The lack of RAM in the 32X and the inability of the SH-2s to access any of the Sega CD's extra RAM is going to make any decent 3D game on the 32X CD combo difficult without extra hardware. This is not to say that it's impossible (that open source GBA 3D engine and its level data was quite small), just a pain.

Well well well.
Are you in a hurry ?
Please, let me finish my grDraw2DLine routine, then my grDraw2DTriangle routine. Then, let me start projections, and create 3D primitives counterpart. Let it be flat shaded.
Then, let me learn about gradient.
Then, hope some CPU cycle remain, and, maybe, I'd consider texture mapping.
But for now, for heaven sake, ... let me get there ;)

Mask of Destiny wrote:

commodorejohn wrote:There's one thing I have to say about this whole idea:

Quake 32X CD.

The lack of RAM in the 32X and the inability of the SH-2s to access any of the Sega CD's extra RAM is going to make any decent 3D game on the 32X CD combo difficult without extra hardware. This is not to say that it's impossible (that open source GBA 3D engine and its level data was quite small), just a pain.

Yeah, probably.

They were planning a 32X Descent port, though - that might work.

commodorejohn wrote:They were planning a 32X Descent port, though - that might work.

Don't tell my wife a Descent port was in stage ; she would ask me to complete it !!!

I wish they had =/

Has anyone looked at the Descent source code?

http://www.descent2.com/ddn/

The PC source is a lot of assembly but the Mac source is mostly C.

I couldn't say if it's doable but it could be an interesting project.

There's actually been a source port of Descent 2 to Windows, so it's definitely feasible to make another version from the source. If I were doing it I'd do it for 32X CD, as that means more RAM and unlimited storage space (i.e. no cutting out of textures or simplifying of levels to fit in a cartridge.) Basically I'd have one SH2 driving the game logic, one doing the rendering, the Genesis 68000 and Z80 reading input and driving the music (I think the music could work pretty well on YM2612 if someone put together a good MIDI patch library and used sampled drums,) and the Sega CD 68000 doing file loading and sound mixing (hooray for multi-channel PCM chips, eh?)

Of course, the best part is that on 32X one could do it in RGB color rather than trying to do variable lighting in 256 colors. Although Descent did do that very well considering.

Also, someone totally needs to make a decent 32X CD DOOM port.

Edit: Hmm, wait, if the SH2s can't access the Sega CD RAM, maybe it would be better to have one of the 68000s running the game.

From SuperVDP topic :

Chilly Willy wrote:If you're writing words, remember a framebuffer will be 32000 writes for 256 color mode, and 64000 words for 15 bit mode. So 256 color mode is easy to keep going 60 Hz, but 15 bit mode consumes a considerable amount of bus time. Much of the CPU would be devoted soley to writing video data. Yet another reason most folks use 256 color mode for game screens, saving 15 bit mode for static displays.

==> In 3D, one could use VDP fill function to write continous 15-bit data, rasterizing the whole things.

ob1 wrote:From SuperVDP topic :

Chilly Willy wrote:If you're writing words, remember a framebuffer will be 32000 writes for 256 color mode, and 64000 words for 15 bit mode. So 256 color mode is easy to keep going 60 Hz, but 15 bit mode consumes a considerable amount of bus time. Much of the CPU would be devoted soley to writing video data. Yet another reason most folks use 256 color mode for game screens, saving 15 bit mode for static displays.

==> In 3D, one could use VDP fill function to write continous 15-bit data, rasterizing the whole things.

Yes, that would work for flat shading. Not so good for textures. Too bad the VDP didn't have a COPY mode like the MD VDP. Well, I SUPPOSE you could use the 68000 as a DMA copier - compute the start in the texture memory, the destination in the frame buffer, and the dx/dy steps, then pass it on to the 68000 to actually copy the data. Of course, you could use one of the SH2s the same way. Have the 68000 in the CD do the game logic, have one SH2 do the 3D calculations and rasterizing, and have the other do the actual drawing. You'd still need to be careful about bus utilization - someone is STILL going to have to write all the data to the frame buffer. Just as a guess, I'd say that using the main 68000 to write the data to the framebuffer would hold the SH2 off their bus the least. Using one of the SH2s to draw to the frame buffer would still consume most of the available SH2 bus time. The SH2s would be held from ROM during the 68000 fetch (not applicable to 32X CD), but would still be able to access stuff while 68000 waited on the frame buffer FIFO (assuming the 68000 is fast enough to saturate the FIFO).