Jump to content

Is there any port of Doom for Virtual Boy or Zeebo?


Recommended Posts

If anyone makes this, I feel that the right thing to do would be to make it the way all Doom ports were done in the 90s.  Developers changed the game to make up for the limitations of the consoles they were working on.  They worked to make their version special and come up with things the others didn't have.

 

Obviously Doom 64 did this the most by a wide margin.  But think of the 3DO with a real band doing the music, PSX reverb, or even the exclusive levels and monsters like Club Doom and the Nightmare Spectre.

 

It would be kind of a "what if" experiment.  Not just making a port, but anticipating who would have worked on it, where they might screw up and what they would do to make their port distinct.

 

Every 90s port had a different HUD, for crying out loud!  The Saturn port was a direct copy of PSX Doom, minus the features that were more than it could handle, and they still went to the trouble to give it a cooler HUD.

 

If anyone is inclined to do this with Virtual Boy or even Dreamcast, that would be awesome!

Edited by rabidrage
Clarity

Share this post


Link to post

It's completely posible to do in a Zeebo, the problem is the console itself. It was only sold in Brazil and Mexico iirc and making a port will require having the actual console to test it since theres not emulator for it. So yeah, pretty hard work for just a curiosity.

Share this post


Link to post
On 9/9/2022 at 4:38 PM, rabidrage said:

Obviously Doom 64 did this the most by a wide margin.  But think of the 3DO with a real band doing the music, PSX reverb, or even the exclusive levels and monsters like Club Doom and the Nightmare Spectre.

Virtual Boy: Supports proper 3D vision depth-of-field.

 

Zeebo: Is in Brazilian Portugese. HUEHUEHUEHUE

Share this post


Link to post
On 9/10/2022 at 1:43 AM, Herr Dethnout said:

It's completely posible to do in a Zeebo, the problem is the console itself. It was only sold in Brazil and Mexico iirc and making a port will require having the actual console to test it since theres not emulator for it. So yeah, pretty hard work for just a curiosity.

Or you just buy a HTC Dream/T-Mobile G1 handset and develop a game for that since the Zeebo is essentially the same hardware in a console shell.

Share this post


Link to post
On 9/12/2022 at 11:05 AM, Dark Pulse said:

Virtual Boy: Supports proper 3D vision depth-of-field.

 

Zeebo: Is in Brazilian Portugese. HUEHUEHUEHUE

 

Well.  Yes.  But what else would developers have randomly done to compensate?  A custom level?  A new monster?

Share this post


Link to post
2 hours ago, rabidrage said:

Well.  Yes.  But what else would developers have randomly done to compensate?  A custom level?  A new monster?

Probably nothing.

 

Virtual Boy would have enough trouble just running the game.

 

Zeebo was way after Doom's main period of commercial viability, and their ports of stuff like Quake II, besides the translation, were absolutely bog-standard with nothing extra.

Share this post


Link to post
  • 2 weeks later...

Taking the opportunity to revive the topic, there is still no news of a port of Doom for Virtual Boy, but finally we can say that Zeebo can run Doom.

 

 

And the Zeebo port of Doom looks way better than I expected, honestly I'm surprised that someone offered to port to such an unknown console.

Share this post


Link to post

Had to look up the Zeebo - never heard of it before. Looking at the tech specs, it's no surprise it can run Doom - it should be capable of running a pretty modern source port like gzdoom!

 

Share this post


Link to post
14 hours ago, Moonie said:

Taking the opportunity to revive the topic, there is still no news of a port of Doom for Virtual Boy, but finally we can say that Zeebo can run Doom.

 

 

And the Zeebo port of Doom looks way better than I expected, honestly I'm surprised that someone offered to port to such an unknown console.

Its actually a recent publication this port! Done by TripleOxygen who has done much for the Zeebo in general.

 

Even so, some more details:

  • Its a port of PrBoom 2.5.0, meaning that Boom-compatible wads may run.
  • Homepage is here.
  • There are caveats:
Spoiler

doom

Port of PrBoom 2.5.0 to Zeebo. Started in 2012 but frozen for several years. It is not a full port, see details below. However, it is “playable” for the most part, with both shareware and retail WAD.

 

Video:

 

 

What doesn't work or hasn't been tested

 

  • Music (works, but not along with sounds)
  • Options menus, savegames, etc.
  • Exiting the game causes the console to reboot

Installation

The process is the same used in any console games.

  1. Get the latest version from the Downloads area ( prboom-xxzip )
  2. Extract the contents of the ZIP to the root of an SD card. After extracting, you will see 2 folders on the SD: mif and mod.
  3. In the mod/prboom folder, place a valid Doom WAD, along with the other files (prboom.mod, prboom.wad, etc)
  4. You can use “doom1.wad” from the shareware version, just search for “doom wad shareware” in your favorite search engine
  5. If both shareware and retail WADs (doom1.wad and doom.wad) exist on the console, the game will use retail (doom.wad)
  6. All file names must be lowercase
  7. Insert the card into Zeebo, open EMAPPLET , go to “Field Test” and run Memory Copy.
  8. After copying, restart the console.
  9. Ready! It will be available as “PrBoom” in Appmgr. If you want to add on Z-Wheel, read below.

at Z-Wheel

As the Z-Wheel only shows the apps that are configured on it (it doesn't show all installed on the system), the game will not appear in the list.

You need to edit your copy of Z-Wheel to manually enter the game:

  1. With the copy of your Z-Wheel on the SD card, extract the prboom-0.1-z-wheel-assets.zip file (in the Downloads area) inside the 274755 folder;
  2. This will add the game data inside the “assets” folder
  3. Still in folder 274755, open the database “tt_game_info” of your Z-Wheel in some editor for db SQLite (this one, for example https://sqlitebrowser.org/ );
  4. Run the following SQL:
  5. INSERT INTO GAMEINFO VALUES (30000001, 17028710, 0, 0, 0, './assets/games/30000001/', 0, 512000); INSERT INTO TITLETEXT VALUES (30000001, 538996325, 'DOOM'); INSERT INTO TITLETEXT VALUES (30000001, 538997605, 'DOOM'); INSERT INTO TITLETEXT VALUES (30000001, 538997872, 'DOOM');
  6. Save and copy back to your console via Memory Copy.
  7. Ready!

controls

  • Movement with the thumbsticks
  • left thumbstick X axis generates movement with strafe ;
  • thumbstick rotates the camera and overlaps the strafe if both were triggered simultaneously;
  • Home - menu
  • ZR - Shoot / Confirm
  • ZL - Simulate the 'y'/'yes' to exit the game
  • 1 - Run
  • 2 - Use / Open
  • 4 - Change weapon

downloads

Binaries

Most recent first.

Additional

source code

Coming soon.

 

4 hours ago, ChillyWilly said:

Had to look up the Zeebo - never heard of it before. Looking at the tech specs, it's no surprise it can run Doom - it should be capable of running a pretty modern source port like gzdoom!

 

I doubt it runs GZ - The Adreno 130 in the Zeebo is at best an OpenGLES 1.1 renderer. Maybe DoomGLES, but PrBoom is already more than just classic Doom.

Share this post


Link to post
On 9/13/2022 at 2:36 PM, Dark Pulse said:

Probably nothing.

 

Virtual Boy would have enough trouble just running the game.

 

Zeebo was way after Doom's main period of commercial viability, and their ports of stuff like Quake II, besides the translation, were absolutely bog-standard with nothing extra.

 

Not that I don't see your point, but look at what was done on the SNES.  And they included translucency for the weapons when you got the Invisibility Artifact, as well as better music and the ability to change weapons while paused.  Not to mention strafing via the shoulder buttons.  Some of those things might not be to your preference or a huge deal at all, but it ran, and they did fuss with it.  What you said about viability and the other ports, however, is absolutely relevant and can't be ignored.

Share this post


Link to post
38 minutes ago, rabidrage said:

 

Not that I don't see your point, but look at what was done on the SNES.  And they included translucency for the weapons when you got the Invisibility Artifact, as well as better music and the ability to change weapons while paused.  Not to mention strafing via the shoulder buttons.  Some of those things might not be to your preference or a huge deal at all, but it ran, and they did fuss with it.  What you said about viability and the other ports, however, is absolutely relevant and can't be ignored.

The SNES version of Doom literally had the benefit of a coprocessor, though. The actual SNES CPU itself couldn't even manage Wolf3D at full speed and resolution; it wouldn't have had a prayer of running Doom.

 

I mean, if you put a coprocessor in, you can pretty much theoretically do anything, up to the limits of the coprocessor and communication with the system hardware can handle.

Edited by Dark Pulse

Share this post


Link to post
4 hours ago, Dark Pulse said:

The SNES version of Doom literally had the benefit of a coprocessor, though. The actual SNES CPU itself couldn't even manage Wolf3D at full speed and resolution; it wouldn't have had a prayer of running Doom.

 

I mean, if you put a coprocessor in, you can pretty much theoretically do anything, up to the limits of the coprocessor and communication with the system hardware can handle.

 

I guess the question, then, is how powerful the Virtual Boy is compared to that SNES/coprocessor combo?  After all, Virtual Boy is of a later console generation.  Granted, it was designed for a different way to play, just like handhelds were always traditionally weaker than standard consoles of their generation.

Share this post


Link to post

The VB processor is on par with the SH1/2 at the same frequency, but lacked a cache. Doom would run on it about like the original Doom 32X (maybe, probably a bit slower). The main issue with Doom on the VB is lack of memory - it's only got 64KB of work ram. You might be able to repurpose some of the vram... not sure how flexible the VB is about setting up the display and then using left over memory for other things. That's a trick D32XR uses to deal with low memory. I think you'd need to completely rewrite Doom to make it work on the VB, much like the SNES needed a complete rewrite.

Share this post


Link to post

From what i've read, it's possible to add up to 16Mb of RAM in the Virtual Boy cartridges, that's more than enough to run Doom without problems. The main issue is that the cartridge bus is 16-bit wide, and that currently doesn't exist any cartridge with such configuration.

Share this post


Link to post

The bus width isn't much of an issue. The bus on the 32X is only 16 bits. The SNES bus width is only 8 bits. As you say, the issue is that no cart out has the ram on the cart to make use of. You'd need to make a custom cart for the game, which would increase the expense.

 

Share this post


Link to post

That's pretty cool. Too bad the info behind it is lost to time - the associated web page isn't in the internet archive, and google can't find anything. :(

 

Having worked on Yeti3D for the 32X and the N64, I can say that getting it working on the VB is a real accomplishment! I imagine he really had to squeeze to get the data to fit in 64K - Yeti3D is designed around a minimum of 256KB (the amount of ram in the GBA and 32X). Yeti3D Pro is designed around at least 2MB of ram.

Share this post


Link to post

For Virtualboy Doom, I'd probably suggest to start with the GBA homebrew port: https://github.com/doomhack/GBADoom

Given that the GBA is ARM@ 16.78 MHz it's also quite low-powered. Screen Resolution is however lower on the GBA compared to the VirtualBoy: 240 × 160 vs 384×224 (So the VB has basically 40% more pixels to drive).

Share this post


Link to post
On 10/5/2022 at 10:27 PM, M2m said:

For Virtualboy Doom, I'd probably suggest to start with the GBA homebrew port: https://github.com/doomhack/GBADoom

Given that the GBA is ARM@ 16.78 MHz it's also quite low-powered. Screen Resolution is however lower on the GBA compared to the VirtualBoy: 240 × 160 vs 384×224 (So the VB has basically 40% more pixels to drive).

It's also got less ram than the VB does, though both can nominally have their working memory expanded. Both would also benefit from being ROM cartridges, though, enabling rapid swapping of texture data as needed.

 

Also, while it's true the VB does have that higher rez screen, a mitigating factor is also that its refresh rate is roughly 50 Hz.

Share this post


Link to post
15 hours ago, Dark Pulse said:

Also, while it's true the VB does have that higher rez screen, a mitigating factor is also that its refresh rate is roughly 50 Hz.

 

Plus the GBA can even run Quake 1:

 

Share this post


Link to post
  • 3 months later...
On 9/26/2022 at 10:39 PM, rabidrage said:

 

Not that I don't see your point, but look at what was done on the SNES.  And they included translucency for the weapons when you got the Invisibility Artifact, as well as better music and the ability to change weapons while paused.  Not to mention strafing via the shoulder buttons.  Some of those things might not be to your preference or a huge deal at all, but it ran, and they did fuss with it.  What you said about viability and the other ports, however, is absolutely relevant and can't be ignored.

None of these were special features specifically crafted for the SNES version. The way the player's weapons look when you have partial invisibility is a compromise (it's just using the SNES's built-in hardware transparency; same reason Spectres were removed, the original partial invisibility effect couldn't be done). "Better music" is subjective and they certainly weren't intending to beat the PC version (though I think it sounds pretty great), it's just supposed to be an approximation of the original*. Strafing via the shoulder buttons was standard on console FPS games. The only true enhancements are changing weapons while paused and the automap that spins.

 

The only ports at the time that had stuff specially crafted like you imply, were the PS1/Saturn versions. At best you may be able to say the Jaguar/Jaguar-based ports also kinda did, with their Doom 2-ification of the levels and other features, and it's new levels to replace certain PC levels, and its lack of bosses... or many things that make Doom feel like Doom to be honest... but again, most of this is due to compromise and wasn't intended to feel like exclusive features. I don't consider Doom 64 a port, it is it's own mainline entry in the Doom franchise for me, after Doom, Doom 2 and Final Doom (which I also consider a mainline entry). The SNES version was supposed to have exclusive features and enhancements, it was meant to use its own mapset that would have worked better on SNES, and was meant to have various gameplay enhancements, but id Software did not like these changes and wanted it to be as close to the PC version as possible, so the mapset used in the final version only has minimal, necessary changes. You can still see some of the gameplay enhancements in the source code, there's a bunch of compilation options labelled "useID" or something like that which enable and disable the changes that id rejected.

 

*Actually, I'm pretty sure the music was actually automatically converted like the 32X version - the game credits Paul Webb as the arranger, and VGMPF.com says that he arranged Bobby Prince's MIDIs, but we know the latter can't be true as neither Randy Linden nor anyone else on the dev team had access to any Doom development material. As the timing sounds slightly off (but not enough to sound bad) in a lot of songs, it suggests that Webb converted the songs from the MUS lumps, known for having strange timing, and the sound driver Webb used (used in other games he worked on) doesn't play nice with non-standard timing (this is also evident in Boogerman, whose songs are missing tempo changes present in the Megadrive version, and uses the same sound driver as Doom). So I think Paul Webb was only responsible for the sound driver and cleaning up the converted output (probably like assigning instruments to the channels).

Share this post


Link to post

I believe for Virtual Boy a port that uses the cut down console maps seen in several other ports would work best. The game would need to have graphics adjusted, not just the textures and sprites, but the lighting effects too, so that it wouldn’t be too much of an eyesore.

Share this post


Link to post
  • 1 year later...

Obviously, the Virtual Boy was just too ambitious to be either a handheld or a dedicated console to begin with. I wouldn't think that a Doom port based on the Jaguar version would've increased sales in 1995-96 even it it wasn't released on said system. Besides, Nintendo has quietly and unofficially "Disowned" the system, which is why none of the games on the Virtual Boy have been re-released, remade or remastered on their newer hardware.

 

Perhaps using FastDoom would be a better option for a homebrew Virtual Boy port.

Share this post


Link to post
11 hours ago, Wadmodder Shalton said:

Obviously, the Virtual Boy was just too ambitious to be either a handheld or a dedicated console to begin with. I wouldn't think that a Doom port based on the Jaguar version would've increased sales in 1995-96 even it it wasn't released on said system. Besides, Nintendo has quietly and unofficially "Disowned" the system, which is why none of the games on the Virtual Boy have been re-released, remade or remastered on their newer hardware.

 

Perhaps using FastDoom would be a better option for a homebrew Virtual Boy port.

Many of FastDoom's optimisations are through x86 assembly and would be of no use to a port for another architecture.

Share this post


Link to post
  • 3 weeks later...

I would love to play a Virtual Boy port of Doom, but it would probably require some extra processing power inside the cartridge itself. As for the easiest version to make it work on, theoretically speaking if we had the full source code of every single Doom console port then the easiest to port would be SNES given it is much simpler, however it would just be PC Doom since, well, if we're gonna be putting a RAM expansion inside the cartridge, we might as well go for it instead of trying to do another Jaguar Doom.

Share this post


Link to post
6 minutes ago, Roebloz said:

theoretically speaking if we had the full source code of every single Doom console port then the easiest to port would be SNES given it is much simpler

I mean, if you call converting SuperFX assembly code to NEC V810 assembly code "simple," sure...

Share this post


Link to post

For the VB, you would probably need to rewrite stuff in order to get it to fit in memory, and cut out plenty of assets. Cut out weapon animation frames and use offsets to replicate missing frames, use the Jaguar mapset and textures, and cut out animation frames for enemies (while making sure you don't do an SNES Doom where enemies instantly open fire on you without warning). Squashware Doom might be of use for this, though you'd also wanna do manual adjustments to graphics, like Poom does.

Share this post


Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...