Printable View
Just out of curiosity let's pretend that Sega never even thought of the 32X and stuck with the SVP, releasing Virtua Fighter and Daytona USA with it and maybe perhaps still making consoles today?? :lol:
Anyway, would a Doom port have been possible using the SVP chip? Would it have had to use a custom engine similar to the Super FX 2 SNES Doom? Could it have been even better than the SNES port? I've read that the SVP was more powerful than the Super FX 1 & 2.
Yes. And it would probably run quite better than the SNES one, the real question is: are you able to stomach Doom at 16 colors?
These questions/what if threads suck IMO.
I'd rather not have any of them in this section of the forum which was created upon Chilly Willy's request for in-depth technical discussions, homebrew development, etc.
Yikes. Still, an informative post- not quite sure where else op’s question could fit in the forum.
Well, for 16 colors... https://www.youtube.com/watch?v=YFFWw3n6XlY You can have a glimse of it with Ega DooM... but... For me Zero Tolerance is a really great game, so Doom with SVP... hell yeah! :D
But that's without dithering and with a horrible palette, it could look alright I think.
Edit:
https://i.imgur.com/bkbIWFl.png
Based on the SNES port (104 to 16 colors). Pretty sexy right?
Can the Genesis really dither on the fly? I would have expected the dithering pixels in assets scaling up with everything else.
This would be the SVP though.
Worth noting that in these cases usually pixels are doubled horizontally for the sake of speed. The reason it matters in this particular case is that two pixels make up a byte, and so doing that can speed up rendering significantly by being able to overwrite the whole byte directly instead of having to read, modify and write back. And since there's nothing saying the two pixels have to be identical, that's essentially dithering for free (albeit vertical dithering, though there are ways to work checkerboard from there on).
Probably the best example of this would be the Wolf 3D demo, dithering is used heavily there (note: I'd suggest using dynamic mesh mode instead of fixed mesh x_x doors look atrocious in the latter).
https://i.imgur.com/uzwU5qy.png
https://i.imgur.com/xpgTReC.png
Yeah these what if threads are a bit crap really :/ maybe if we ever get a SVP FPGA (not likely) we'll know.
Jeez sorry, I really am curious and am a big Doom fan. I actually do like playing the Doom 32X port once in awhile since I consider it a novelty (I just hate the music obviously). It would be actually pretty astounding if someone were to pull it off homebrew wise. Nonetheless thanks for the informative post.Quote:
Originally Posted by Barone
This. I was thinking of the 32X forum at first but that wouldn't make much sense.Quote:
Originally Posted by ironnick23
Yes! That is actually surprisingly pretty decent looking.Quote:
Originally Posted by Alianger
Once again, sorry! That'd be great although very unlikely. I would imagine it would only be worth putting on a flash cart if even. Or maybe perhaps on a Reprogrammable flash chip cart for one game.Quote:
Originally Posted by matteus
Doomguys hand would have its own palette though, and the UI could use one independent of the rest of the scene with a mid scanline palette switch.Quote:
Originally Posted by Alianger
The background would also have its own BG layer and possibly the ground too.
There are three palettes free for use for anything that isn't the framebuffer and your first thought is to use a raster effect to load the HUD colors instead of using one of the free palettes? :v
Ground can't have a separate palette from walls though, unless you want the framerate to plummet (due to the much higher amount of data to transfer each frame). The ground isn't at a fixed height so you can't just draw it on a layer behind the raycasted graphics.
It doesn't look like this thread is sucking AT ALL.
Also now's a good time to remind us on why an SVP game is limited to 16 colors / 1 palette
Because all it does is render to some buffer in (its own) RAM and you still have to go through the console's VDP as usual. Basically all the same issues as with the Sega CD.
You'd be better off creating a virtua series style FPS...Quote:
Originally Posted by Sik
It still isn't blatantly obvious for us programming illiterates as to why then most Mega CD games go beyond those 16 colors limitation. Heck, some of the most most colorful games on the system are on CD. Also SVP Virtua Racing may only have 16 colors or less when drawing its polygons, but the background looks like it uses way more than that
Well it doesn't! You might be being fooled by the use of dithering.Quote:
Originally Posted by chilled
The games on the cd aren't doing anything special the tiles all pass through the same colour limited VDP. So anything you're seeing is simply good palette usage. I'd say Core were pretty good at it ')
SoulStar does have more colours onscreen. 1 palette is used for the far background (plain 2D), one for the "mode-7 landscape effect"-like bottom plane, one for the main sprite, bullets and HUD, and one for the enemy sprites. It only really works in a game like SoulStar though.
Batman and Robin (CD) uses the same 16 colour palette for everything except the 2D far background and the HUD. Now that's some excellent use of 16 colours, even if the overuse of dark blue gives it away.
Yes but I was meaning 16 color total, afaik the 16 color per palette also applies to any MD game, right?
Sure, but the issue with the Sega CD or the SVP is how they display what they render (it has to go through the normal Genesis hardware).Quote:
Originally Posted by chilled
Lets say you want to render an entire display, full of scaled sprites or whatever, into just a single background layer.
Sending that amount of data to the Genesis VDP will decrease your framerate to around 15 frames per second, already assuming it is highly optimized.
Since it is all one background layer and there are no clear tile boundaries (since you are just drawing a bunch of sprites/polygons into it), you're limited to 16 colours.
Now lets say that to work around that you use the two background layers. You draw some things to one and some things to the other, each with its own palette.
That's technically two screens worth of pixels you're drawing. Your game is 7.5 fps now. Unplayable by any standard, so you can't really do that.
Lets say you try to optimize the overlap between layers as much as possible (so that only the boundary of the layers really needs overlapping tiles). You can probably get around 12 fps like that but that's assuming the extra CPU overhead to manage this isn't eating your framerate instead.
There's simply a hard limit to how many total pixels can be 'plotted' into the VDP per frame on the Genesis, so you have to cut them down as far as you can.
SoulStar never draws more than half a screen worth of background (which it sometimes mirrors to cover all the screen), so that it has some bandwidth for the scaling sprites.
Even with big black bars and a big hud on top of that (such that the background is more like 30% of the screen) it only manages 20 fps in the best case.
Oh fuck, I completely forgot that Doom has skies (the mock-up didn't show an area with a sky so I wasn't thinking on that). Yes, the sky can easily go to the other tilemap layer with its own palette. You even avoid sky-specific code (since color 0 in the foreground will let the sky show through, so it comes for free).Quote:
Originally Posted by chilled
So huh...
- Palette 0: framebuffer
- Palette 1: sky
- Palette 2: HUD
- Palette 3: Doomguy
And
- Plane A: framebuffer + HUD
- Plane B: sky
- Sprites: Doomguy
And in case you wonder: yes, Virtua Racing has the sky in the other tilemap layer, so it gets to use the other palettes.
Battlecorps uses two palettes on the field (ground has one palette, objects have another palette - no idea if the sky has its own palette too). The problem is that this requires loading two framebuffers instead of just one, so it reduces how large the viewport can be while retaining a decent framerate (and fitting in memory, too).Quote:
Originally Posted by matteus
Quote:
Originally Posted by chilled
lolno(EDIT: wait, just noticed you said 16 color per palette, not 16 color on screen - yes, it's per palette, explanation below still is relevant anyway)
There are four palettes with 15 colors each + transparent (plus the background color, so 61 colors total without raster effects or S/H). Each tile is limited to 15(16) colors, which is where the limit comes: you probably aren't going to want to waste time trying to figure out which palette to use on each tile of the framebuffer, it's already hard enough to draw everything fast enough as-is. You could do the dual framebuffer thing that Battlecorps does, but now the size is halved if you want to retain the same specs (Battlecorps gets away with it because it uses the mech frame as the HUD, giving it a good excuse to eat a lot of the screen with that).
The limit only applies to the framebuffer, so HUD or sprites overlaid on top or background under it etc. are all not affected and generally are given the remaining palettes.
EDIT: by the way, while chances of anybody ever doing anything with the SVP are slim (you'd be better off grabbing a cheap low-spec ARM CPU for homebrew :v), all this discussion could also easily apply to an original game too.
Yes because the HUD is perfectly separated by a line from the rest of the content. And you'd be using 1 palette for the raycaster, 1 palette for the backgrounds (not ground/ceiling, but the background that some stages have), 1 palette for the hands holding the weapon, and then you have the HUD which has a bg, a font, and doomguys face.Quote:
Originally Posted by Sik
For the best colour count you could use 2 palettes for the hand graphics and 2 or 3 for the HUD. Maybe the HUD could share some with the hand, I dunno.
Which adds up to four palettes... (this is why I pointed out the raster effect was pointless, you don't need it)Quote:
Originally Posted by zyrobs
I'd make Doomguy's face share the same palette as the hand/weapon though, there seem to be more colors in common with it than with the HUD (you could make the face a sprite on top of the HUD, it's not like sprites are being hogged here).
You don't have to be limited to 16 colors, you could have 31 colors using 2 planes (and 2 palettes), but in this case to draw the background sky you have to do it in the same framebuffer, ie draw background sky first then render walls, sprites, objs... this will be done with SVP (or some other chip), the weapons/hands will be done with sprites. Also reducing resolution height a litle and extending Vblank period will help to make transfer to Vram faster.
You can even go further by using S/H to get a maximum of about 60 colors still using 2 palletes: one for planeA and the other for the sprite layer(instead of planeB), in this case you could use planeB as the background sky, and the weapons/hands will be drawn in the framebuffer after everything else. :)
In both cases the HUD and the face will share 1 palette.
If you see how Doom on the snes is made, it uses the mode 3, which means a 256 color mode, has a resolution in the rendering view of 216 x 144, and a full resolution (counting the HUD) of 216 x 176, but despite the fact that it looks that the game only have half horizontal resolution, ie 108 lines instead of 216, it really has 216, so that means that it has a framebuffer of 31KB and it needs at least 3 frames to send the full framebuffer to Vram, because it have about 86 scanlines(by extending vblank) per frame for DMA.
This way, using 2 Planes (or one plane and sprite plane)if you use the same resolution on the Gen/Md as on the snes it will use the same amount of memory for the framebuffer.
Combining two layers as a framebuffer? Sounds risky.
Are we sure there's enough vblank bandwidth to update a reasonably large screen? If there isn't, is there enough VRAM for double buffering?
And then we're hitting that weird issue where using both layers for a framebuffer means you need to use sprite overlays for the Shadow/Highlight and oh no. :daze:
It's times like this I wish the Everdrive had SVP support :) I'd love to see you try and implement something like this.Quote:
Originally Posted by gasega68k
I'm sure gasega68k has a good idea of what he could get away with :) He did Wolf3D so I'm pretty sure he could implement Doom :DQuote:
Originally Posted by Flygon
Bandwidth isn't the only problem, the SVP would have to draw to both framebuffers too. So not only you get twice the penalty on transfers and memory usage, but also on processing power.
Honestly I'd rather stick to one palette and deal with it.
Hi there.
Forget about colours. Do someone know how to make a 'hello world'?
There is no scene for SVP, I think.
Why SEGA never release a dev kit for SVP?
Probably because there was no need for one. No third parties made SVP games.Quote:
Originally Posted by danibus
Sure, but sometimes "someone" found a dev kit, a manualsomething...
If SEGA release dev for SVP, there will be a new Genesis era.
The SVP was quickly dropped by Sega for two reasons: 1) It cost too much, and 2) It had some unknown performance or reliability issues.
Hideki Sato very briefly mentions the last point in that big interview he did, but he doesn't really give details. He just says something to the effect that Samsung's manufacturing quality wasn't up to par and Sega lost millions on it.
Even if the SVP wasn't worth using for additional projects, similar chips could have been used for games of various scope.
But SNES Doom only happened because Nintendo was dragging their heels again and waiting too long to join the next generation. Although quality Mega Drive software should have continued to flow longer, it didn't make sense to use a pricey chip for a game that wouldn't sell better than a quality game without a chip, once the Playstation and Saturn shipped.
Trying to blur the line between generations also only hurts the appeal of your current next gen console.
But what if now they release how yo code svp?
We can try in emulators and *maybe* build a cartridge?
Is possible?
I think that it's a waste of time and effort making out of spec games for classic consoles. The few who have the skills and talent to push polygons on the base MD hardware have already produced some amazing results. I'd also like to see more 2D games than anything mostly 3D based. Games which make use of the Mega-CD hardware would be a much better investment and not require harvesting VR carts.Quote:
Originally Posted by danibus
The problem with the SVP is: where the heck do you get one? (without sacrificing Virtua Racing cartridges) It may be easier to pick something else as coprocessor.
No idea about that, but some time ago we were trying to figure out how the heck SVP got its data (since it's in the ROM, yet doesn't look like the 68000 passes the data to its RAM?), and one suspicion we have is that the SVP may be doing cycle stealing and reading the ROM whenever the 68000 is out of the way (since even between memory accesses there's still at least one free cycle if I recall correctly?). That requires a really fast ROM though, which definitely would make the price skyrocket (which probably explains the $100 price tag, as opposed to just being the SVP).Quote:
Originally Posted by Gryson
SNES Doom was made because somebody started on his own then saw it was taking off and offered it to the publisher he was working for (who promptly got the Doom license).Quote:
Originally Posted by Black_Tiger
https://gamingreinvented.com/intervi...-randy-linden/https://web.archive.org/web/20150108...m-history-1994Quote:
And what was it like being a programmer on the project? What challenges did you have to overcome to get it working on the SNES?
I started the project independently and demo’d it to Sculptured Software when I had a fully operational prototype running. A bunch of people at Sculptured helped complete the game so it could be released in time for the holidays.
The development was challenging for a few reasons, notably there were no development systems for the SuperFX chip at the time. I wrote a complete set of tools — assembler, linker and debugger — before I could even start on the game itself.
The development hardware was a hacked-up StarFox cartridge (because it included the SuperFX chip) and a modified pair of game controllers that were plugged into both SNES ports and connected to the Amiga’s parallel port. A serial protocol was used to communicate between the two for downloading code, setting breakpoints, inspecting memory, etc.
Quote:
a SNES version of DOOM *was* created in secrecy by Sculptured Software; they presented a final, finished SNES version of DOOM and sent it to us asking if we wanted to publish it; oh hell yeah!
If a group of ex-Core members came out of nowhere with not only a promising, but complete and ready to ship impressive port of Virtua Fighter 3 for Saturn, which used a 3DFX card adapted to fit the Saturn's cart port... Sega wouldn't have published such a pricey CD/cart combo at a time after the PS2 had already launched.
Lobotomy's supposed secret super port of Quake for Playstation never got published, even though it didn't require expensive additional hardware.
Judging by how quickly SNES Doom got discounted, the fact that I never met anyone who actually bought it (I seemed to be the only one who rented one of the many copies at Blockbuster)... and the massive number of manufactured copies... I think it's safe to say that the game wasn't worth publishing. But it's cool that we got it (and Virtua Racing).
If you want to make 3d for Sega, go grab a Dreamcast.
But that isn't fun :v
Well the Saturn is available too, if you want to make ithardfun ;) Plenty more Saturns than SVPs.