Hello everyone! My name is Sam Kennedy and I’m currently developing games on the SEGA Dreamcast and SEGA Virtual Memory Unit and I have been thinking of porting my game to the Virtual Boy. When I came onto the site on of the news posts where saying that if you won a conpetion you got a limited run of your game and I started to wonder who would I contact to get my game published to a cartrage? If anyone would be so kind to send me the email for said person or send their website I would be thankful. 🙂

Sent you a pm 🙂 or if you see me on..message me at the top of the page (chat).

We’re really not publishers or anything. But, there are some people here that try to make games for the community to enjoy. Just some fanboys 🙂 But, if you have questions..just ask. We’ll try to help you out.

-Eric

*Visual Memory Unit (VMU)

You should worry more about your ability to produce a Virtual Boy port than whether publishing is available. The tools and resources available for Virtual Boy pale in comparison to Dreamcast. If your game is good, publishing will find you.

SirGuntz wrote:
*Visual Memory Unit (VMU)

You should worry more about your ability to produce a Virtual Boy port than whether publishing is available. The tools and resources available for Virtual Boy pale in comparison to Dreamcast. If your game is good, publishing will find you.

Sorry I was on my phone when i wrote this, so auto correct will be playing up lol. Also creating a port will not be too much hassle as I all ready have my own game engine for my company that me and are a couple of friends are starting up so one piece of code for multiple platforms. So its really just learning how the VB ticks and basing it off that.

What platform(s) are you porting from? Dreamcast? You’d get better speed from the Virtual Boy if you build the engine from the ground up, it’s not exactly a beast of a console.

Affection: You can start by finishing the 2 virtual boy games Mario Kart: Virtual Cup and Mario VB then make a forum post once the game is finished and someone here will probably make a box art for you

The big problem is that not alot of VB carts around and the cheap once people already used so the key is to find cheap carts wherever and put your game into it unless you can make ur own cart with the chip insuide to store your game but finish the games and someone here will help you layer on with the box art, carts and so on

SirGuntz wrote:
What platform(s) are you porting from? Dreamcast? You’d get better speed from the Virtual Boy if you build the engine from the ground up, it’s not exactly a beast of a console.

I’m porting from Dreamcast, Visual Memory Unit and X86 PC’s however we just got a dev kit from Sony for the PlayStation Vita and we’re waiting for word from Mircosoft and Nintendo about the Xbox One and Wii U. We know that the Virtual Boy is’t a powerhouse but our own programming langauge called ‘CrystalScript’ cuts out alot of hassle over high level programming langauges have, by still allowing some low level features such as memory allocation so you still have the control and better optimation than most high level languages. Now what we’re most happy about over here is the the compiler we’ve created, it isn’t like C where the compiler is Trans-compiled, our language is compiled using a technique called Machine code generation, that compiles staight to Binary without steping down to an other language.

affection wrote:
We know that the Virtual Boy is’t a powerhouse but our own programming langauge called ‘CrystalScript’ cuts out alot of hassle over high level programming langauges have, by still allowing some low level features such as memory allocation so you still have the control and better optimation than most high level languages.

The Virtual Boy with an unmodified original FlashBoy has only 64KB of working RAM– 8KB of additional SRAM if you have a FlashBoy+. A generic memory allocator with its required overhead probably would have little use within such boundaries. Most games I see try to use statically allocated RAM (usually just temporarily) and try to offload generation of things like LUTs and other data to the compile phase, rather than at runtime, to take advantage of the comparatively ample ROM space.

Unless you’re just learning the basics or making a very simple game, the VB really isn’t the place for high-level “scripting” languages. If you want to make a serious VB game, using C and dropping down to V810 assembly in critical sections is the only practical way to do it. The community’s biggest struggle within the past few years has been getting our toolchain cleaned up and modernized from an ancient version of GCC 2 built back in the mid 90s.

Now what we’re most happy about over here is the the compiler we’ve created, it isn’t like C where the compiler is Trans-compiled, our language is compiled using a technique called Machine code generation, that compiles staight to Binary without steping down to an other language.

So… you created the equivalent of GCC? 😛 (I kid, I kid)

Hmmm, that’s going to be a problem as my co-workers don’t know alot of programming so I created the easy to learn scripting language so i could have the game’s progress going at a steady pace whilst I create ports to other platforms, So I’m going to have to teach them C what is going to be a pain. Do you think I could use the Flash memory from the FlashBoy to off load some of the files from RAM? Also is there any VRAM in the VB or does it just use the normal RAM for graphics?

Haha, an equivalent of GCC, I think not, more like a hours and hours of reading “Let’s Build a Compiler, by Jack Crenshaw” and questioning the folk at stack overflow haha. The joys of being a self taught programmer.

this may interest you: http://www.planetvb.com/content/downloads/documents/stsvb.html

You could still use your custom scripting language on Virtual Boy, but your games will lack efficiency and thus be sluggish. A JRPG would work quite well, a fast paced action game or shooter, no. Any game that would require a lot of calculations during gameplay would see a drop in speed with a high level language instead of C or ASM. You can hide calculations behind the JRPG’s normally slow nature.

affection wrote:
Do you think I could use the Flash memory from the FlashBoy to off load some of the files from RAM? Also is there any VRAM in the VB or does it just use the normal RAM for graphics?

If you include the OAM area, which is shared between the graphics processor and the CPU, then the VB has a grand total of almost 200K of usable RAM, but this area of memory is physically located elsewhere on the motherboard and isn’t as fast as the WRAM (http://www.planetvb.com/modules/newbb/viewtopic.php?topic_id=5369&forum=2) The Flash memory on the FlashBoy is an EEPROM which is programmed using the FlashBoy software on a Windows PC. Once programmed it’s no different than ROM to the VB itself. A good idea as mentioned in my previous post is to precompile graphics and lookup tables into ROM, rather than generating them dynamically in the sparse RAM, especially if they’re static once created.

blitter wrote:

affection wrote:
Do you think I could use the Flash memory from the FlashBoy to off load some of the files from RAM? Also is there any VRAM in the VB or does it just use the normal RAM for graphics?

If you include the OAM area, which is shared between the graphics processor and the CPU, then the VB has a grand total of almost 200K of usable RAM, but this area of memory is physically located elsewhere on the motherboard and isn’t as fast as the WRAM (http://www.planetvb.com/modules/newbb/viewtopic.php?topic_id=5369&forum=2) The Flash memory on the FlashBoy is an EEPROM which is programmed using the FlashBoy software on a Windows PC. Once programmed it’s no different than ROM to the VB itself. A good idea as mentioned in my previous post is to precompile graphics and lookup tables into ROM, rather than generating them dynamically in the sparse RAM, especially if they’re static once created.

Wow, 200kb? I know it was under powered by I never knew by that much. I think I’ll just write the games in ASM intead really and not bother with the Virtual Boy Target. it’s a shame really as I was really hoping to make a console like experience with minimum ease. Anyway, thanks for that URL, that’ll definitely come in handy.

Well, it is a bit silly to expect so much from the Virtual Boy. This was 1995, with expensive LED displays and mechanical oscillating mirrors, not to mention the the manufacturing costs… There wasn’t much room to offer a Playstation here. It’s easiest to treat the Virtual Boy like a “16-bit” successor to the Game Boy, with a really big screen resolution.

I don’t think you should give up before even starting. The VB may have only 64K of WRAM but that didn’t stop T&E from making Red Alarm, a game with huge and detailed 3D levels, which, by the way, uses 24K of that RAM just for the replay buffer.

On PCs and disk-based consoles, you have to load data from disk to memory before you can use it. On cartridge-based consoles, the CPU can access ROM data as if it were RAM, so this means you really only need the WRAM for the game state.

And 20 MHz is probably faster than you think. It isn’t quite fast enough for texture-mapped 3D graphics but probably fast enough for pretty much anything else. So I don’t think you’ll have to throw away your scripting language, although writing the interpreter (or parts of it) in assembly is not a bad idea if you really need it to be that fast.

Maybe if you gave us some examples of games you would like to port, we would be able to suggest optimizations. You will certainly need to cut down on graphic quality etc. but I think nobody has used the VB yet to its full potential.

HorvatM wrote:
I don’t think you should give up before even starting. The VB may have only 64K of WRAM but that didn’t stop T&E from making Red Alarm, a game with huge and detailed 3D levels, which, by the way, uses 24K of that RAM just for the replay buffer.

I’m not giving up or anything, I’m just merely rethinking my strategy on how I’m going to tattle development on Virtual Boy.

HorvatM wrote:
On PCs and disk-based consoles, you have to load data from disk to memory before you can use it. On cartridge-based consoles, the CPU can access ROM data as if it were RAM, so this means you really only need the WRAM for the game state.

Really? That is awesome! I’ve not done much in the way of cartridge development so that is awesome!

HorvatM wrote:
And 20 MHz is probably faster than you think. It isn’t quite fast enough for texture-mapped 3D graphics but probably fast enough for pretty much anything else. So I don’t think you’ll have to throw away your scripting language, although writing the interpreter (or parts of it) in assembly is not a bad idea if you really need it to be that fast.

Yeah,I might as well write an interpreter for my scripting language.

Maybe if you gave us some examples of games you would like to port, we would be able to suggest optimizations. You will certainly need to cut down on graphic quality etc. but I think nobody has used the VB yet to its full potential.[/quote]

Okay, I’m currently developing a side scrolling hand-drawn Hack ‘n’ Slash RPG. Here is a screen shot. (VERY MUCH IN WIP)

Attachments:

1. 

   wildfire-picture-for-vb.png
   

I must say it’d be really awesome to have a game like that on the VB.

Probably the biggest hurdle you’ll face with Virtual Boy is trying to wrap your head around creating 3D graphics. The good VB games always make use of it, by giving some graphics more depth than others, or making then appear far away and close.