mic
Moldy Popcorn
Posts: 27
|
Post by mic on Jul 12, 2010 3:51:02 GMT -5
The vertical scaling can be done using the 32X's line table, but the horizontal scaling would cost you. If you just did 2x scaling horizontally it'd only cost a couple of extra cycles per pixel (which still adds up to a lot of cycles for an entire frame), but you've limited yourself to a horizontal render resolution of <= 160 pixels, which is likely to look like crap. If you use a higher render resolution (e.g. 240 pixels) it'd require some interpolation to upscale it to 320 pixels, which would take even more time.
|
|
|
Post by jlf65 on Jul 12, 2010 14:14:58 GMT -5
True, I didn't even think of the line table. That would make vertical scaling easy. A few extra cycles to scale a line would be less than actually rendering the line, I would think. I might play around with it more later. Busy on other things right now. I just wanted to try a quit port to see how it would work, and it only took an hour or so for what I did there. The code is included (it's GPL - the code HAS to be included), so anyone can mess around with it if they like.
|
|
oompa loompa
I AM THE GOVERNATOR
"Git 'Er Dun!"
Posts: 1,301
|
Post by oompa loompa on Jul 12, 2010 15:13:54 GMT -5
Aw no hardware scaling/rotating on the 32x? Liars ! You can double pixels horizontally using the RLE format mode. Downside to this is that you're constrained to a 256 color palette. Actually it kinda doesn't make sense for this kind of application because the same thing can be accomplished with the regular 8BPP format mode with palette as well (still writing 2 bytes for one logical pixel)
|
|
|
Post by jlf65 on Jul 12, 2010 20:18:07 GMT -5
Yes, RLE would work for 256 color screens. That's probably the easiest way to double the screen horizontally. Yeti3D works in thousands mode - either BGR555 or BGR444.
|
|
|
Post by GiGaBiTe on Jul 13, 2010 1:08:19 GMT -5
If I were to make a Quake 32x port, I'd do a 32x CD game. Use both SH2s for rendering and both 68000s for game logic. Not enough ram. With a cart, you can at least stuff a lot of the data into the rom. With CD or CD32X, EVERYTHING has to go into the ram. You'd have to edit the levels to remove a lot of details and textures. Or make a version where it loads for every room. ;D Remember that the CD only has 768 KB of ram, and the 32X only 256KB. Trying to stuff a Quake level into that amount of ram would be a real trick. Now a "quake-like" game specifically written around the CD32X lack of ram could be done. Run the game logic on the CD 68000, the sound and glue logic on the MD 68000, and the rendering on the 32X. It wouldn't be hard to make a 4 or 8 MB RAM cart to put in the cart port and have the SegaCD just load data into it. Standard Quake levels don't use more than 4 MB of texture data You can probably RLE the textures and make them smaller since many of them have big blobs of the same color. The only issue would be the ~30 second load time for the CD to fill the cart (4 mb) with data.
|
|
|
Post by jlf65 on Jul 13, 2010 2:02:01 GMT -5
A plain 4MB ram cart that worked with the SCD would be a godsend for SCD homebrew. The number one thing that limits most homebrew on the Genesis/CD/32X is lack of ram.
|
|
|
Post by Syniphas on Jul 14, 2010 17:49:36 GMT -5
So are we doing Quake on the 32x or not???
|
|
|
Post by jlf65 on Jul 14, 2010 18:20:01 GMT -5
So are we doing Quake on the 32x or not??? Yes, but at the moment it will require a Neo Myth to provide the necessary ram. I've gotten the source for QuakeDS, and learned some lessons with my port of Yeti3D. If someone comes up with a ram cart that works with the CD, I'll be one of the first to get one and make a version for the CD/RAM cart in place of the Neo Myth.
|
|
|
Post by Tom Maneiro on Jul 14, 2010 18:24:23 GMT -5
Looks like if you don't want to use kustom kartridges with extra RAM and expensive mappers, we would have to release one ROM per level HEY! What about a Lock-On(tm) system? Separate the game engine from the level data - this will allow to change levels by just attaching a new level ROM bank (for PC emulators and cheap flashcarts, just use "copy /b base.32X+level.bin quaked.32x" (for Windows) or "cat base.32X level.bin > quaked.32X" (for all others)... Obviously a level "compiler" would have to be coded from scratch, and for maximum space, the Quake engine should be crammed in as litte space as possible.
|
|
|
Post by jlf65 on Jul 14, 2010 23:28:26 GMT -5
Hmm - I'm not sure how much ram Quake needs for things other than graphics and level data. One level per rom with the info stored in save ram would be one way to handle it if there was enough ram in the 32X. I'll keep that in mind while I'm converting the code over to the 32X. It was one thing I was considering for Doom as well - a full Doom, but one level at a time. No problem for emulators and flash carts.
|
|
|
Post by TheMVRules on Jul 16, 2010 11:54:49 GMT -5
What about Quake...without textures. That would be less ROM/RAM consuming and will reach higher FPS. And then you could ignore the PWM and only use FM synthesis, to save CPU cycles and ROM size.
|
|
|
Post by Tom Maneiro on Jul 16, 2010 13:30:25 GMT -5
Well, the SNES DOOM version did exactly that for saving resources: they don't bothered with ceiling and floor textures, just walls. So it could be an option.
|
|
|
Post by Syniphas on Jul 16, 2010 15:23:30 GMT -5
Guys, here's some ideas (they're mostly from Andlabs, from Sonic Retro)
-use CDDA, not FM or anything like that -the SH-2s apparently share 4mb RAM, look into that -use a SH-2 ASM rendered (Andlabs said to be developing one)
and this could really happen...
|
|
|
Post by jlf65 on Jul 16, 2010 16:20:01 GMT -5
That's 4 Mbits, not 4 MBytes... and it's only 2 Mbits, not 4. The 32X has 256 KBytes of SDRAM for both SH2s to use.
|
|
|
Post by GiGaBiTe on Jul 16, 2010 20:54:08 GMT -5
Well, the SNES DOOM version did exactly that for saving resources: they don't bothered with ceiling and floor textures, just walls. So it could be an option. The problem with removing the floor and ceiling is that unlike Doom, Quake is a full 3D engine. Many levels have water / slime / lava and bridges over parts of other floors. It would look really bad to say the least. One thing that should be gotten rid of is the scrolling sky, it would use up massive amounts of CPU time to render which could be used elsewhere. A simple parallax card sky would be a decent replacement.
|
|