RunnerPack wrote:
1) Limited to Windows BMP files for input
I’m trying to keep it simple. If you need other formats, you can use ImageMagick or something to convert them. I’ll add support for images with fewer colors though so you won’t have to waste space with 24-bit BMPs. Although NTFS compression works quite well on them.
2) User is required to specify all filenames, without extensions
This makes it harder to use in a makefile.
What’s your proposed alternative?
3) Only C or raw binary output
C takes longer to parse, and binary requires an asm “stub” to link. GNU assembly output shouldn’t be too hard to add, right?
Right. What does it need? A label and a list of .dbs? I’m not very familiar with the GNU assembler – I’ve only used it with the asm() macro in C code.
I think you should continue, but you should also learn proper programming techniques, such as how to split up code into functions and how to use arrays. If you would have, the game would be much more finished by now.
Greg Stevens wrote:
I’ve never used a flash boy but assuming it uses a standard usb storage device interface I doubt it would be very difficult to create a simple app.
You guys have it all wrong. It is a little known fact that one of the codenames for the Virtual Boy was Yob Lautriv, but Nintendo changed the name slightly before the release when they already had some manuals printed, so this is a really rare collector’s item. I bet Benjamin Stevens will offer you a lot of money for that one.
Benjamin Stevens wrote:
Even with that, though, I don’t think either Waterworld or Virtual Lab has an in-game high score that one is supposed to beat, and making it to level 99 in Virtual Lab would likely take a person more than 100 hours of continuous play, while making it to level 99 in Waterworld is a complete impossibility.
Not only that, you’d also have to be lucky for Virtual Lab not to reboot (is that just a myth or does it really do that?).
Also, I have just searched through its code and there is no special score that you have to get. The highest readable score you can get is 327670; after that, it displays garbage, and once you get to 655350 (which you can’t see), it starts at 0 again.
I’m not sure how you would get to level 99 (actually 100, but stored internally as 99) anyway, as I usually can’t get past level 7 or so.
I remember there being a bug in the past that caused badges to disappear and members’ post counters to display -1. Maybe that’s what happened. I’m sure KR155E would make an announcement if badges were being removed.
Craby wrote:
I did not want to make a thread for just a (probably) stupid question, so I will ask here :
Is there a way to create a multiboot-rom / homebrew compilation / to merge several little roms into one 2048ko rom ?
I use my FB+ mainly for homebrew, that would be very handy 🙂
HorvatM once posted (can’t find the thread anymore) that he wrote an tool that can merge 2 roms into one. There was a problem with running the merged rom on hardware though. Also I don’t remember if he published the tool itself.
I don’t think there exists a proper solution right now.
I didn’t release the program, but if you want, I can continue working on it so that it hopefully becomes useful.
There will never be a fully automatic ROM joiner though because to join two or more games, you have to hack each one to be compatible with the others (most of the work can be automated, but you still have to do some things manually). So probably the best way to do this is to make pre-made compilations of games. Even then, some games would be incompatible with others if they use all 8 kilobytes of SRAM (they would erase each other’s data, but otherwise they would work fine).
I also think that digital TV and widescreen displays are bullshit.
With analog TV, I could watch movies in rural areas even if the picture wasn’t perfect. With digital TV, unless the signal is perfect, the picture is unwatchable and there is no sound at all.
Widescreen displays are completely useless on a PC unless all you do is watch movies. Maybe we should have square displays, they would be good for any purpose.
These “innovations” were obviously designed to make everyone “upgrade” their decades old 4:3 analog TVs by requiring us to buy those stupid converter boxes and then leave a quarter of the screen unused because of those black bars.
I do hope though that 3D TV becomes the affordable norm (possibly in an analog form :D). 3D TV for a 3D world. Hell, all pictures everywhere should be 3D if it makes sense; most of us have two eyes and we should use them both.
One of my complaints about the VB is that many sprites are two-dimensional — in “Wario Land” all characters are paper-thin. Our home-brew games promise they can deliver “3D sprites” — like in Mario Cart and others; I’m excited about that.
The problem with stereoscopic sprites is not only that it’s harder for the artists, but also that it can use twice as much character RAM, limiting the variety of graphics you see at a time, and it also halves the number of sprites you can have at a time.
I’m really pleased (and not a little jealous!) at those writing new games for the VB; hope it continues, and hope we eventually will come up with copies of the “Holy Grails” (especially Dragonhopper, Zero Racers, and Goldeneye). I confess I never thought I’d get to actually play “Bound High” — it’s one of the best games!
I think we should create original games, so the Ballface situation of wasted(?) effort wouldn’t happen again.
I think vb-fan was trying to remind us of an unwritten rule all VB fans should follow: thou shalt have no virtual reality systems before the Virtual Boy.
Anyhow, the Oculus Rift can’t natively run VB software, so it doesn’t qualify as a VB clone.
I did some comparison between the two ROM images. To compare the code, I used the function that seems to load BGMaps (and does something else?), as it writes to the address 0x20000.
The disassembly is modified from David Tucker’s disassembler’s output.
To me, BSS seems to be compiled with a non-VUCC compiler, because it copies $SP to $29 and then uses $29 to access local variables. VUCC always modifies $SP directly with ADD or ADDI, though it is sometimes MOVEA’d to a temporary register ($10 to $19) in the Insmouse code, but I’m pretty sure this is only done to address elements of a local array. Also, when passing parameters to a function (before a JAL), it goes from left to right – starting with $6. VUCC always starts at the right, finishing with $6.
Now look at PVBSS: it simply pushes everything to the stack, no weird tricks with the $SP. The JMP at 0x1258 is a bit strange, but this occurs all the time in Virtual Lab. There are also redundant SHL/SAR instructions everywhere to sign extend registers (VUCC does this a lot, gccVB not so much). And parameters are moved to registers from right to left.
I have also thought about it. I think that a clone of the VB should be similar to the real VB in all aspects due to its simplicity, but obviously the design should be less fragile. The goal should be simply to make the VB and its games more accessible to people interested in it. There should also be an easy way of using it as a 3D display device for a PC and video output so we wouldn’t have to bother with cameras.
But I’m not sure what medium it should use for software. Cartridges are obviously expensive. Am I the only one who doesn’t have a memory card unit? Or is everyone on laptops?
No it wouldn’t. Physical copies (on cartridges) would still be just as rare. And you can already download ROM images of VB games, though the legality of this is questionable.
I don’t know much about the first-person view, but I know that it’s composed of multiple worlds/BGMaps, and all sprites (items, monsters, the crosshair, HUD icons, timer numbers) are objects:
41B78 – pointers to charset for each monster kind (4 words)
9A8F8 – charset for monster kind 0 (1024 characters)
9E0F8 – charset for monster kind 1 (1024 characters)
A20F8 – charset for monster kind 2 (1024 characters)
A60F8 – charset for monster kind 3 (1024 characters)
AA0F8 – charset for floor/walls/ceiling (256 characters)
AB0F8 – charset for floor/walls/ceiling, “moving parts” (I forgot what that means, probably doors)
AC0F8 – charset for floor/walls/ceiling
AE0F8 – charset for non-monster sprites
B90F8 – first-person view BGMap – charseg 0 is AA0F8
BB0F8 – same as B90F8, but for different eye
BD0F8 – BGMap for all doors – charseg 0 is AA0F8
BF0F8 – same as BD0F8, but for different eye
C10F8 – unknown BGMap – may be related
C30F8 – C10F8 for different eye
C50F8 – unknown BGMap
C70F8 – C50F8 for different eye
All addresses, except for monster charsets, are hardcoded.
Everything is uncompressed and loaded with the functions I listed before.
There are probably pointer arrays for the sprites, but I haven’t discovered them yet (well, actually, I know where a lot of pointers are, but I don’t yet know what they point to).
Dark monsters use the same characters as bright ones, but a different palette.
My plan is to eventually put all of this onto my Web site to create the ultimate Insmouse resource, but my perfectionism prohibits me from doing it right now, and I’d have to translate everything first anyway.
So, just tell me what things you want to replace and I’ll give you the addresses. If you’re going to map things I haven’t yet (mostly ending cutscenes), it will be helpful to know these two functions:
8482 (LoadBGMap)
$6 -> source
$7 = index of BGMap (0 = 0x20000, 1 = 0x22000, etc.)
Note: BGMaps are always 8K
84A6 (LoadCharset)
$6 -> source
$7 = destination character data index divided by 256 characters (gets multiplied by 0x1000 and added to 0x78000 to produce the destination pointer)
$8 = number of words to copy (1 character = 4 words)
If you want to load BGMaps that are smaller than 8K, you can use this function:
13154 (CopyMemH)
$6 -> source
$7 = number of halfwords to copy
$8 -> destination
