|
Post by jlf65 on Aug 23, 2010 17:16:40 GMT -5
You're tying the /CART_IN to ground... which means the Genesis will think this is a rom cart and try to boot it. You need to NOT pull /CART_IN low.
|
|
|
Post by 3vix6 on Jan 8, 2011 1:21:27 GMT -5
Holy krap.. I ask a simple question, leave for a 6 months come back and it's an 8 page thread! That's Hilarious!
Especially asking a simple question of whether it could be done or not! ;-)
Pretty cool though seeing people talk about the methods of how it could or couldn't be done. That and the fact that someone ported YETI to the 32x.. WOW..
That's not only way cool dedication.. That's just freaking awesome!
|
|
|
Post by jlf65 on Jan 8, 2011 19:31:31 GMT -5
That was me. I found a newer version of Yeti3D, "Yeti Pro", at sourceforge. The old version didn't have any optimizations... I might make some to this version. The 32X definitely needs some optimizations to make 3D fast enough for a game.
Not sure when that will be out, but I'll post if here when it is ready.
|
|
|
Post by GiGaBiTe on Jan 10, 2011 21:40:50 GMT -5
I'm guessing the 32x doesn't have enough power to do a proper Z buffer and will be limited to the crappy affine mapping which results in texture warping. I watched some yeti 3d demos on youtube, and the texture warping was pretty awful, even more so than games on the PS1.
|
|
|
Post by jlf65 on Jan 11, 2011 17:16:06 GMT -5
I'm guessing the 32x doesn't have enough power to do a proper Z buffer and will be limited to the crappy affine mapping which results in texture warping. I watched some yeti 3d demos on youtube, and the texture warping was pretty awful, even more so than games on the PS1. Yes, pretty much. Yeti3D has a "faster" mode that results in more warping on the surfaces for better speed. That's probably what you were looking at. There's no getting around affine mapping on old hardware like this. All you can do is try to minimize the warping when you can.
|
|
mic
Moldy Popcorn
Posts: 27
|
Post by mic on Jan 12, 2011 4:08:13 GMT -5
You could do perspective-correct calculations every Nth pixel and do linear interpolation in between. Which is exactly what Quake did afaik.
|
|
|
Post by jlf65 on Jan 12, 2011 17:12:00 GMT -5
You could do perspective-correct calculations every Nth pixel and do linear interpolation in between. Which is exactly what Quake did afaik. It's called "subdivided affine mapping", and the newer version of Yeti3D looks like it altered how many pixels it does between calculations. I'm hoping it looks better in fast mode. That's one of those things that minimize warping that I was talking about in my last post. Another is tessellating the triangles/quads more; that makes them smaller, which results in something very akin to subdivided affine mapping. It's why some PSX games had bad fish-eye effects while others didn't. ;D
|
|
|
Post by GiGaBiTe on Jan 14, 2011 0:23:49 GMT -5
Could you use both SH2s for rendering and put the game logic on the 68000? Most games, if not all seem to use one SH2 for rendering and the other for game code. I'd figure doing something like triangle setup and matrix math on one and texture filling on another, you'd be able to have a better looking world.
|
|
|
Post by jlf65 on Jan 14, 2011 17:22:20 GMT -5
Could you use both SH2s for rendering and put the game logic on the 68000? While it would seem like a good use of the 68000, the problem is bus contention. The 68000 and two SH2s have to compete for the rom bus - while the SH2s have a cache that can help minimize rom bus contention, the 68000 does not. You can put code in the 68000 work ram to minimize bus contention (I do that in Wolf32X), but it's doubtful all the game logic will fit in work ram with enough space left for variables... if it even fits at all! You would have to run the game logic from rom, which means the 68000 hogs the rom bus, which means the SH2s are slowed. It's just easier for most games to run the game logic on one of the SH2s. Now if you also had the CD, you could put the game logic on the CD 68000 and not have to worry about bus contention. That's my initial plan for Wolf3D for the CD32X - have the game logic on the CD 68000 while the SH2s just render. Yes, that would be faster for "true" 3D. The issue is the rom contention as mentioned above. Perhaps putting certain routines for the game in work ram that were called frequently would leave enough free rom cycles to avoid fighting over the rom by the processors. For example, if your game logic included a loop on waiting for input and/or the vertical blank, that could be put in ram so the 68000 used no rom bus cycles in its wait phase.
|
|
|
Post by GiGaBiTe on Jan 17, 2011 19:08:57 GMT -5
Then let's get Quake on the Sega CD so we can use the 32x solely for rendering.
I've never messed with Yeti3D, but I did manage to port part of the first Doom level to Quake and id looked pretty good for having such low-res textures (even worse than Quake) Since you aren't going to use the Quake engine anymore, guess it's time to learn Yeti3D sigh.
|
|
|
Post by jlf65 on Jan 17, 2011 21:40:11 GMT -5
I never said I wasn't going to use the Quake engine, but do look at Yeti3D... if it would be better for a Doom conversion, then that might be the way to go. The main limit I see with Yeti3D is everything is made of cubes; not sure how well Doom levels would look done as cubes. Here's the link to the latest Yeti3D - Yeti3D Pro: sourceforge.net/projects/yeti3dpro/
|
|
|
Post by GiGaBiTe on Jan 20, 2011 21:29:24 GMT -5
I looked at the level editor and it's not nearly as bad as I thought. I'd still much prefer the Quake engine over Yeti, as it's an established engine that many people know about and still develop for.
As for the cube thing, it looks like Yeti supports patch meshes, or something like them, so I don't think making diagnol walls would be too much of a problem.
|
|
|
Post by defzonoc on Apr 13, 2011 4:19:16 GMT -5
naa its real easy to make a ram cart find a dirt cheap old cart or do the breadboard stuff or google "card eadge connectors" pic your pattern. there are new EEPROMS with <70ns WRITE speed so ANY static ram newer then 92 should be fine. got a 486 with socketed cach ram use that. but STATIC ram is needed DYNAMIC has a odd address scheme compared to roms not to mention its row and columb refresh mess. i just have 256k EEPROM on mine though it was an experament i did a long while back for a segacd game. i tried to load up to it a sega game and reset it and it ran. same with the 32X. but when i do a RAM CART i cant reset it because the ram could be erased even with a battery backup and im not sure how to turn on the 32X from a running genny but ill get it one day. ;D inspite of what others say. and i give this advice free of gratuities or insults.
|
|
|
Post by marvio on May 27, 2011 23:18:43 GMT -5
Hello all there! New to the site here (so go gentle) I'm not sure if anybody is keeping this "project" alive, but if it's goign on, I'd like very much to help. Love to see this in action! I'm no programer, but I could definitely crete low poly models/textures/animations if needed. I could also convert/re-create the music to any format necessary, from FM sythesis to a CD track. For that matter I could compose new music, if you guys like... Note, this is just an offer, because othet then that all I can contribute is by saying "You guys are doing an awesome job" (which you are, but...); I just thought to mention that because I made the same offer on some other homebrew site, and got my head bitten off because "3d modelers are a dime a dozen", maybe, but I just wanted to help, you know?
|
|
|
Post by GiGaBiTe on Dec 12, 2011 4:57:06 GMT -5
I think this project is pretty much dead, unless jif65 randomly comes in and posts he has 90% of the game code completed.
Assuming we used the Sega CD, it can play Redbook audio (Audio CDs) and you can make a hybrid disc with both data and audio tracks to include the Quake OST without modifications.
The rest of the game content could be reused without modification, since you're only porting game engine itself. Textures might be an issue with the limited VRAM though.
|
|