[RunnerPack]

I’m sorry, but I can’t fill in the ellipsis in your last statement 😛

Also, I disagree with your statement. I think Reality Boy is both *good* and (fairly) *accurate* but, if you can do better, go for it.

Anyway… I was under the impression that PSFs are all the same, structure-wise, and only differ in the executable code inside, which comes from the game ROM itself, and the emulation code used to play them. See: http://wiki.neillcorlett.com/PSFFormat

In which case, all we need are a reasonably accurate VSU emulation core (i.e. one that supports DogP’s ingenious volume change technique) and someone to strip the non-sound-related code from the ROMs and compile them into “VSF” files. Enough is known from the v810 architecture documents to know what instructions do what, and the Wiki has all the info on what address locations do what, so… there ya go 😛

I suppose someone should contact “the authorities” (Neill Corlett?) and reserve a version byte (0x24?) and the “VSF” extension. Also, some custom tags might be necessary.

(As a side note, I doubt miniVSFs will ever be required/useful.)

If you want to be the one to do all that stuff, more power to ya! 😀 (of course, I’ll help out if I can…)

• This reply was modified 16 years, 6 months ago by RunnerPack.

[RunnerPack]

VirtualChris wrote:
Also, I had to use a goto statement in order to make this work. Can anyone tell me how to make it work without it?

Just put your “while(1)” loop contents in a loop with an exit condition and put that and the “level_start” code inside the “while(1)” loop–which should actually be a “for(;;)” loop, I’ve been told, since it skips the superfluous testing of 1 each time through. Here’s an example for the inner loop:

int keep_looping = -1;

while (keep_looping) {
.
.
.
    if () keep_looping = 0;
}

I think you’re a very talented programmer, you just need to spend some time with a good C reference and try to absorb what the language has to offer. You’re good at knowing what needs done, you just need a larger vocabulary of tools and constructs with which to do it. I like that you used a function to check the BGMap (which I distinctly remember telling you to change 🙁 ;-)) but you need to carry that through to the rest of the code. Encapsulation is one of the keys to efficiency and re-usability (not to mention readability…).

Keep at it!

• This reply was modified 16 years, 6 months ago by RunnerPack.

That looks a lot better (going a little heavy on the whitespace, but I can’t fault you for that).

It only takes a quick look in libgccvb.h and the wiki, but here is a quick run-down of vbSetWorld:

vbSetWorld(#, flags, GX, GP, GY, MX, MP, MY, W, H);

#: The World number to modify
flags: Visibility, BGMap number, Mode, etc.
GX: The horizontal position of the upper-left pixel of the World
GP: The parallax offset of the World
GY: The vertical position of the upper-left pixel of the World

MX: The horizontal position of the upper-left pixel of the source rectangle
MP: The parallax offset of the source rectangle
MY: The horizontal position of the upper-left pixel of the source rectangle

W: The width of the source rectangle, minus 1 (e.g. 383 for full-screen)
H: The height of the source rectangle, minus 1 (e.g. 223 for full-screen)

I found another problem: you’re not setting an end World. The first unused World should have the WRLD_END flag set, otherwise, every World will be drawn, wasting time and, on hardware, probably generating random garbage on screen.

I’m not sure about your terminology, but, if I understand you right, it’s actually a good idea to use different Worlds for different layers of the level (obstacles, “mice”, etc.).

What I was referring to in my first post was the practice of accessing the BGMap data to see what to collide with. It will be much more robust and “future-proof” if you use a map stored in a smaller format (like an array of unsigned chars) and use that for both collision testing and generating the BGMap data. Like so:

static const u8 level_one[16] = {
    1, 1, 1, 1,
    1, 0, 0, 1,
    1, 0, 0, 1,
    1, 1, 1, 1,
};

The real one will be much bigger, but you know what I’m getting at… You can also use an array of arrays, like so:

static const u8 level_one[4][4] = {
    { 1, 1, 1, 1 },
    { 1, 0, 0, 1 },
    { 1, 0, 0, 1 },
    { 1, 1, 1, 1 },
};

Also, that will not be sufficient for a complete level description. There will likely be some other data associated with a level. For that, you should use a struct. Any good C tutorial will help you with that.

Hope that helps!

Because you’re testing for the value of a BGMap cell, but to perform movement you’re moving the World itself (with GX and GY).

Other problems include:

1. Still using spaghetti code (goto label)
2. Reinitializing the VPU every time through the loop
3. Copying the Char/BGMap data to the VPU every time through the loop
4. Moving, then testing for collision, then moving again if collision detected

I would use a u8 array (or array of arrays) to store the levels and use the graphics data for what it is: graphics data.

Sounds like a good game to work on, though. Are you just going to translate the levels, try to make up your own, or both? What about coming up with new hazards/puzzle elements (its been forever since I played it, so I can’t suggest any :-P)

Looking forward to the finished product!

All that work is probably better spent on a more compatible emulator, and all that money is better spent on an HMD with which to view said emulator. 😀

[RunnerPack]

The expansion possibilities on the VB are huge!

There is an entire second address space the size of the ROM space (but writable) that’s also accessible on the cart connector. The backup (save-game) RAM space, underutilized in most commercial games, is also the same size. That’s 32 additional megabytes of address space on top of the maximum 16MB of ROM/FlashROM. Basically, the sky is the limit…

IMO, adding a large chunk of 16-bit-wide SRAM (for ease of interfacing) to the backup space would give a good performance increase for little cost. It would allow for large lookup tables and fast (one wait-state) executable space for, e.g. self-modifying code. It could even be used to increase space in the ROM, since code and data could be decompressed into and executed out of this space. It may even be possible to port Linux or another OS to the VB! Battery backup (so that commercial games can be saved) could be an issue, but I have some ideas about that. If new parts can’t be found, one possible source of SRAM chips could be old (Pentium era) cache modules.

Of course, as you mentioned, co-processors are also a possibility. There are some quite powerful-yet-inexpensive microcontrollers out there, but even something as simple as a PIC or AVR chip could be of use (perhaps the chip that performs the USB connectivity could pull double-duty). This topic is so large it really needs more space than this post to give it justice…

There are other concessions to expansion in the cart, too. For example, both the left and right audio signals pass through the cartridge connector on their way to the speakers. Something that either produces sound or alters the signals coming from the VSU could be added. I’ve often entertained the idea of attaching the SPC700 audio processor from an SNES to the cart bus. Although it wouldn’t fit inside the cart, you could add a connector to carry power/data to the SPC and audio back from it. (See: this page for almost all necessary details.)

I’ve given this a lot of thought (probably too much ;-)) and I would love to be part of the design process for the “FlashBoy 2” 😀

• This reply was modified 16 years, 6 months ago by RunnerPack.
• This reply was modified 16 years, 6 months ago by RunnerPack.

http://www.vr32.de/modules/dokuwiki/doku.php?

http://www.vr32.de/modules/dokuwiki/doku.php?id=graphics_overview

Congratulations, everyone!

An extra “way-to-go” for VirtualChris for letting everyone watch his game develop in the forum and for (grudgingly ;-)) trying to expand his programming vocabulary beyond BASIC!

It looks like only 27 people voted, though, which seems a bit low. Where were you guys?! How many other “jzagals” were there that just forgot to vote?

See also: Figures 25 through 27 of U.S. Patent No. 5,682,171 and their related text.

I’ve actually modified a floppy connector to fit the link port. You do have to take quite a lot of material off to make it fit, but the ones I used seem to be holding together. I attached a before and after shot (which might be kinda dark if you don’t have your gamma set properly). The actual connector I used for the cable didn’t have that much removed and actually has enough left on it to center it and all that. I can’t find it, though 😛

It seems to fit pretty well, but I’ve never actually transmitted anything over it, because (I think) I wired up the other end wrong (I tried to make a VB<->LPT cable). I may fix it, someday. It’s just one of the MANY, MANY projects I never seem to find time for…

Attachments:

1. 

   floppy_connectors.jpg
   

They used to be–almost literally–a dime a dozen. Now… probably still quite cheap :-P.

I agree. I had to save it (I might use it for wallpaper or something).

I think it’s also technically quite interesting, because somehow your camera was able to capture all the text (which occurs over time) and still get a sharp picture of the LED array producing the pixels. Mind-boggling…

Lookin’ good, Danny-boy! 😉

Now, just make a full game, release the code or (the preferred option) do both! 😀

This is just speculation, not having read it yet, but they could be referring to the fact that A) the mirrors for both displays are mounted on the same armature and, thus, move in opposite directions, and B) the displays are scanned in turn, rather than simultaneously. Of course, if they used the word “screen”, that is definitely a mistake.

@DanB:

DEFINITELY, always keep the “cameras” parallel when rendering stereo CGI. Simulating the swiveling of a person’s eyeballs is called “toe-in” and almost always causes more problems than it solves (we don’t want to make all those evil reviewers from the mid-90’s correct about the VB causing headaches, do we? :-P).

(You probably already know this, but) if you want to control where the “screen” plane is (no screen in the VB, of course, but you know what I mean, I hope) you need to leave some columns off of the left and/or right of the two generated images. This allows for things to “pop out” of the center of the frame, but can cause problems if things at the edge of the frame lie in front of the virtual screen plane. According to the “gun hand” sprite in the screen-shots (I still haven’t seen the real thing) you seem to be doing that now in Yeti. Are the renderings themselves also being shifted?

It’s up to you, of course, but I would avoid “piercing” the VB’s screen. It’s probably okay for the gun-hand, though, since it can’t move out of the frame.

@KR155E:

That is a very useful diagram (despite the English mistake ;-))! Quick, find a spot for it in the Wiki! 😀

Actually, if you look at the first two images as a stereo pair, you’ll see that it’s correct (not “good”, just correct ;-)).

Here it is made into an anaglyph for those with 3-D glasses (red over the left eye). I left the labels on so you can compare the two by covering each eye in turn.

When I’m thinking about 3-D images (such as when making art for VB demos) I try to remember that things farther away move right in the right image, left in the left image, or both.

Attachments:

1. 

   stereo_explanation.png
   

I’m going to go with US Baseball, but I do hope that, even if it’s not something super-rare, it’s at least one of the moderately-expensive/more-popular-and-fun games, like Wario, Pinball, Red Alarm, etc.

But, of course, I would also like it to be something super-rare, like a SpaceWorld demo (even the dolphin one :-P) or an unreleased game (especially since you’ve already agreed to let it be dumped ;-)).

Did you try here:

http://www.rainbowsymphony.com/freestuff.html

I’ve sent for these and they are quite good quality glasses, albeit a bit on the small side. Just be sure you order the red-blue, not the red-cyan; they have less cross-talk and any semblance of “color” you get from the r-c ones (for viewing 3-D photos on the web, or something) is a joke, anyway 😛

It looks like it’s used more for office decoration than actual use…

Have you tried comparing the ROMs (or disassembly listings of them)?

I don’t currently have either compiler installed, so I can’t try it out myself. I hope the problem gets fixed before I do reinstall, though.