[Kresna]

Yes, indeed “ported” games is a modern concept and older games used to had their own versions of games. But i would say that is not a new thing. Old Sega Genesis games where ported to Sega Master System and Game gear several times. Just whit downgrades. And it happened even in the 4-bit Generation era.

My point is that these games are not ported. They are 100% written from scratch; I doubt any of the code in these code bases are shared because the architecture is different. The graphics and audio, too, were all remade for these sorts of games.

And i think this can be done if more people organize and help. Some guys to make the serious programing stuff. Someone to help whit artistic stuff. Someone to translate japanese. Someone to capture and eddit screams….
You gave all the start information that i need. Hope that is someone reading this and enjoy this idea. It would be nice have companion!

I don’t mean to be mean, but I don’t think you will get anyone who will do any of this work for free. The amount of work is in the thousands of hours, and none of it is easy. It would cost thousands of dollars a month to pay someone to do the equivalent amount of work if they were employed. If you are serious about this, the best thing I could recommend is trying to make a small game on the Virtual Boy yourself and see from there if it’s something you want to do. Go into it expecting to have to do everything, all the programming, all the graphics, and all the music yourself. In the end, you might come out with something you enjoy doing, or you might realise it’s not for you.

• This reply was modified 2 years, 11 months ago by Kresna.

The idea that games can be “ported” to another system is a fairly modern concept. When video game systems started becoming more powerful (and especially when they began to share similar architecture to computers), the amount of work to “port” a game to a different system was sometimes worth the effort. However, things become more complicated when you start looking at the retro 16-bit and earlier systems.

The first thing to understand is that there is no easy “tool” to port games. Modern games are ported by rewriting the system-specific code, renderer, and hardware specific features for another piece of hardware. Even that generalises the work too much, it’s still a tremendous amount of work to do, but it’s in the realm of possibility. There isn’t an easy way to do this even on modern systems.

With older systems, the hardware is extremely limited, and games were designed specifically with a systems hardware in mind. On the surface, it looks like all these systems are the same. They’re monochrome, have similar buttons, play similar sounds, but that couldn’t be further from the truth. The way the graphics are produced, how much space you have to store graphics in memory, how backgrounds and sprites work, how the audio hardware works and is played back, all of these things and more are for that one system. There comes a point where you’re no longer “porting” a game and are rewriting it from scratch, which is the next point I want to bring up.

In an ideal world, you have the source code and assets to a game, and maybe, with a lot of work, you’d be able to do something and turn it into something similar on a different system. But with these games, there’s no source code, and even if there was, it would very likely be in a CPU-specific assembly language. The best resource you have to understanding how a game works is using a debugger and disassembler, and, trust me, that’s not fun. You would probably have more success learning a foreign language from zero than disassembling a game to the point where you could understand it enough to reimplement it in its entirety. It has been done, by groups of very talented people for beloved games, but it’s not for the weak hearted. It’s in the realm of difficulty where, if you have to ask how to get started, you don’t have what it takes to do it.

But it gets crazier. Once you’ve disassembled, documented, and understood the game in its entirety, you need to write the entire game from scratch.

That’s right, you need to rewrite every instruction, or reimplement the entire game in a high level language, 100% from scratch.

At that point, you might be best off writing the game from scratch from what you see of it, creating a new engine, and putting recreated assets into a game, which would still take hundreds, if not thousands, of man hours.

The other option is attempting to write an emulator to play older games on more powerful systems, but that’s another can of worms, and in the end, what do you get out of it? Games for other systems were never designed for the VB. They don’t use 3D or depth in any way, and in a best-case scenario you would just have the same game but now it’s tinted red and being shone right into your eyes. If that’s the end goal, you can probably configure emulators to use a custom red palette and call it a day.

But, if you’re serious, and you want to “port” games, the tools are here, they always have been.

Cutter is an extremely powerful reverse engineering tool that can target a variety of different architectures, including the gameboy’s Z80 CPU and the WonderSwan (It uses an intel clone).
The Virtual Boy Development Page has a links and downloads to extremely high quality and well documented tools to start developing for the Virtual Boy.
Mednafen is an emulator that supports debugging of various consoles, including the Virtual Boy and WonderSwan. It’s probably the best emulator you’re going to find for this sort of work on these systems.
WSMan is the best public resource on how the WonderSwan works. There’s other documents in the works, but this’ll get you started.

My final thoughts are that, in the homebrew world, I think I’d rather see new and original concepts for these systems.

Nate wrote:
I really enjoyed this thanks! It gave me a reason to pull out the virtual boy to try something new. Even my 14 year old son thought it was cool.

Thank you for your kind words, Nate! It’s great to hear both you and your son enjoyed my game. It’s nice to hear people are still discovering it months later.

SMVB64 wrote:

Heh, glad you hung around on the ending screen long enough to see it. As for what’s in the game, every asset is used. That means even those anime boy poses are in there. You can see them by using the “action” of one of the effects you collect.

I see, I may have to check again. I used the action button when im a dude and I see the sprite poses. But in the source there’s like full screen art work

Edit – this is what I am talking about
https://i.imgur.com/rjstqmt.jpg

After the sprite pose, press the action button again while Nina is still sparkling, you’ll get the full monty.

enthusi wrote:
I recently was able to play it on Oculus Quest in 3D and it was a beautiful little experience. I really enjoyed this piece of art and felt sad (in more than one way) when it ended.
Thank you for making it and even more so for releasing the sources!

It was a pleasure talking with you! I look forward to what you make for the VB sometime in the future!

SMVB64 wrote:
Fun little game!, you know it gets good when you want more.
Its was pretty intriguing and I liked all the different background effect.

Reminds me a lot off The Witch’s House

also the ending cracked me up

good choice haha

Edit – looking at the source, There is an anime guy doing poses lol. Unused? didn’t come across that when I was playing

Heh, glad you hung around on the ending screen long enough to see it. As for what’s in the game, every asset is used. That means even those anime boy poses are in there. You can see them by using the “action” of one of the effects you collect.

unoclay wrote:
I really liked it. A mysterious vibe, and i caught onto the joke aspects pretty quickly, and though i wont pretend to understand it (even the dadaist ending/meaning/etc) i liked the flavor of the whole thing. It was short enough to play and finish quickly, and it works well. And the graphics are great, especially the void area with the ameoba thing!

Great contribution to the VB homebrew library imho.

It’s great to hear that you enjoyed it. I never really thought much about what people would think of the things we put in, but it seems like it left a good impression on you. The VB community as a whole has made me confident that making this game for the VB was the right decision!

Thanks for playing my game!

clonecman wrote:
This is awesome!! Glad to see a game like this on Virtual Boy! One of my favorite game series, the LISA series, is heavily influenced by Yume Nikki. This is really cool!

Hey, thanks man. It’s great to see people who’ve heard about or played Yume Nikki enjoy this game. Developing for the Virtual Boy was a great experience and I’m glad I chose it as the platform to make this game on.

That’s awesome about the battery life! Glad you’re enjoying it, Nyrator also wrote the dialogue. The effect from the Manga has a special action that the others don’t have, too. Hope you like the ending when you see it! 😉

speedyink wrote:
camping right now in some lake in the middle of nowhere, but when i get back to civilization i’m definitely checking this out

Enjoy yourself out there, and I look forward to what you think when you return!

Lester Knight wrote:

Hi. Having no context for the game or its character, I was really confused if I had reached the ending or not. Thank you for your explanation!

No worries! The game’s character and story are original to this game, so there’s no back story or context to be found other than what you find inside. Nina, with all he dreams and desires, is what you see of her here.

Lester Knight wrote:
Hi.
So, I got to a screen that said FIN after Nina jumped to what seemed like her death? Is this the ending?

I collected a bunch of items (pizza server, 3d glasses, a bike, a manga) but none of them seemed to do anything. The manga got me through a door, but I found nothing useful inside. The bike said it would make me go faster, but did not. I’m confused…

Is the point of the game to collect the items and then to make that jump or am I missing out on something?

Hello!

Yes, that’s the end of the game. Once you’ve collected all four effects and walked to the balcony, the game ends.

This might be the part where it’s a good idea to explain that the game is a satire on the Yume Nikki fan game concept; it’s a joke. Only one of the effects has a function (aside from opening a door), and the bike deliberately does not speed you up. The deeper meaning is simply what’s on the surface. Delicious.

Lester Knight wrote:
I also wanted to ask, are there plans to add music or sound effects? I feel like both would greatly enhance the game.

I hope no one minds that I have attached a padded copy of the 7.19.19 ROM to this post. It was padded using method #3 with the default size (21 – 2MB) and has been confirmed to boot on actual hardware.

Thanks!

I don’t have any plans to continue developing this game. As of now, it’s complete. My goal was to produce something playable for the Virtual Boy in 6 weeks, and I feel that adding content after would be dishonest to the spirit of the project. In future projects, where I can spend more of my own time, I’ll have sound and other features not present here.

As for uploading the ROM, I don’t mind, however I do encourage people to visit the site for the full experience, and for the source code (if interested).

Red Square has been updated and now works on real hardware. This has been tested by Jorgeche. For those of you who want to play it on your real Virtual Boy, now you can do that. The updated ROM is available from the official page. If you want to know what went into it, continue reading.

A lot of work went into debugging this issue from a lot of people, the following things about the game have changed on a technical level:

- Instruction Cache was enabled
- Wait Controller was configured
- VBlank period is now done via VIP interrupt
- VBlank interrupt is waited for using HALT
- Keypad polling was changed to initiate a hardware request at the start of a frame and poll the keys at the end of a frame
- FRMCYC was set to 0 on boot (as is done by commercial games) 

All of these changes didn’t fix the problem, but will provide a much greater battery life when playing the game. Specifically, changing the keypad polling method, and using HALT and the VIP interrupt. The real fix came from a very specific flag in the DPCTRL register.

The DPCTRL register has a flag called DPRST, which automatically resets the display (changing bits in INTPND and INTENB). I set this flag on hardware reset and never unset it. It turns out, this flag never gets unset. What happens when it remains set (it seems) is that every other frame is skipped because DPCTRL resets TIMEERR, FRAMESTART, GAMESTART, RFBEND, LFBEND and SCANERR in INTPND and INTENB. This was discovered when I was debugging retail games and found that their value for DPCTRL ($0302) did not match my value ($0303). My advice? Don’t set DPRST, manually write to INTCLR and INTENB instead of relying on DPRST, and if you do, unset it very shortly after.

A lot of community support went into narrowing down the problem and offering solutions for this bug. The people on the PlanetVB Discord server have been extremely helpful, and I’d like to thank Jorgeche in particular for his time, knowledge, and help in testing and offering solutions to the problem.

speedyink wrote:
Otherwise, this game looks great on hardware. Is this your first 3D game? You’ve done a great job making lots of use of it!
Definitely can’t wait to try this again once it gets sped up 🙂

Thanks! This is my first time making a game with any kind of 3D depth, I think it turned out okay too! The real praise goes to Nyrator if you enjoy the graphics, since he did almost everything you see.

I’ll be sure to post an update when I’ve fixed the framerate issue!

I went to the discord group and user jorgeche tested the rom on his flashboy, and it worked. There was a couple of issues, however. The first was an input bug related to a hardware edge-case (This has been fixed and the ROM updated on the website). The second is that the game’s frame rate suffers on a real VB. We discussed some likely causes and I’ll eventually look into the problem, but it won’t be until some time after the 7th of July.

This means that, though it does run on hardware, for the time being it’s probably best experienced through an emulator. When I get time to sus out the hardware speed issues I’ll post an update.

Hmm, odd. I’ll have to look into what exactly might be causing the issue. It may take some time to debug, especially since I can’t test it, but I’ll see what I can do.

Levine91 wrote:
What motivated you to make it for the Virtual Boy?

Initially it was a joke idea, but the more I thought about the VB the more I thought it would be a fun project. After talking to Nyrator about it over pizza we decided to go all in. It turned out that the hardware is really great to work with.

Aside from that, I enjoy writing assembly, and I’d never written any for a 32-bit RISC processor before this, so it presented a great opportunity to learn.

speedyink wrote:
Very cool! Will be trying this on my VB for sure

That’s flattering to hear! I hope you enjoy it! Let me know if you run into any problems on real hardware. I initialize the VB fairly rigorously so it should work. Mednafen caught a lot of my early mistakes. I don’t actually own a VB (yet?) so I wasn’t able to test it myself.