The right trigger is accelerate. I used to have A for accelerate, but it was too difficult to hold A and press the Right D-Pad to look around. I figured there’s no real need to have both triggers do the same thing anyway. And you can do the spin out (and boost) by hitting the gas and brake at the same time during the start. I’ll put up a video showing some of the features in a little bit.

DogP

Pretty much everything is done with the BGMap… the track is a 2×2 BGMap world (standard image, affine transformed of course), and I have a collision table for each char in the charset to tell whether it’s track, wall, dirt, pit, etc. I check my position in the BGMap to get the char, then check my position in the char with my table for the exact action.

BTW, Thanks for the compliments.

DogP

It could be a number of things… depends on the context ;-).

It could be dumping, as in taking a #2, dropping a deuce, etc:

It could be taking a bunch of trash and leaving it somewhere… either legally or illegally:

Or, I assume you’re asking in the VB context. In that case, it’s reading the data off of a cartridge and storing it as a file on a computer. These are the ROM files, or “ROM dumps” that you can play on an emulator, burn to a flash cartridge, hack, keep as a backup in case something happens to the original cart, or anything else you can think of. It’s similar to ripping a music CD, although that usually involves converting the raw data into a format like mp3. A ROM dump is just a raw binary “dump” of the ROM chip in the cartridge.

DogP

Check out the sticky… that sounds like the typical cable problem.

DogP

I get this every now and then… I believe it’s a bug in the new gccvb that doesn’t move the vectors after the code grows into the vector area until the code actually grows beyond the vector area (ie. code normally will fill up to 1d280, vectors go at 1fde0 to 1ffff, but if code is from 1fde0 to 1ffff, it still tries to place the vectors there, untill code gets to 20000). Whenever it happens to me, I just do a bunch of identical function calls in a row at the startup, until I get enough new code that I can get rid of them.

DogP

Looks good!

DogP

LOL, funny how they tried to tatter the labels to make the fake proto chips look real… and if it’s worth so much, they might want to take better care when they pry the chips out of the sockets (the bottom right pin on the second chip down is bent way out).

DogP

Cool… good luck… my fingers are crossed as well!

DogP

I’m not sure if I understand your questions… fixed point is the same as integers… you’re just interpreting where the point is. If you do shift a signed number to the right (division by 2), you need to make sure you sign extend (or arithmetic shift), but there’s no way to do that with an instruction in C, except division. Most CPUs have an instruction SAR (shift arithmetic right), which the optimizer may take advantage of if the divisor is a power of 2. But if you’re shifting right to interpret as a 16 bit number (like in the FIX7_9_MULT you posted above), you don’t need to worry about it, because the result from the multiply will be sign extended to 32 bits, and shifting right 9 won’t lose the sign bit.

About the bit fields, what is the problem? I would use ints when possible unless you’re using several bytes in a row since integers must be word aligned (and shorts must be half-word aligned), so you’re wasting the space between a byte and an int if you put them consecutively.

DogP

Any picture can be put on the VB, they just have to be converted. Monochrome images (of any color) are the easiest to use though. Many of those pictures would actually look bad if put on the VB though, since we can only use 3 shades of red plus black.

DogP

I plan on releasing the code when I’m done… but who knows when that will be. I’m not sure if I’ll release the full code before it’s “finished”, but I’d be glad to give out chunks of code or make a simple demo using it if it’ll help people use it in their own stuff and understand it better.

DogP

Heh, actually I didn’t realize that I didn’t need to jump on that block… that solves my problem ;-). The problem that I had with it was that the plant wouldn’t come up unless I was close enough to it, and if I go directly to the floating blocks, the plant would never come up. Is that how you intended it? But yeah… of course it’s your game, so make it however you want… just wanted to give you some feedback from a players point of view.

DogP

DEFINITELY use fixed point for as much stuff as possible… floating point is horribly slow. My first Mario Kart engine was floating point (so I could get a working prototype which I could then convert small pieces at a time to fixed point), and it barely ran (just a few FPS). In fixed point, it runs full speed with no problem. I’ve also done some raycaster stuff with floating point and it really is slow.

I don’t know what you’re using floating point stuff for, but I’d assume you can get the precision you need from a 32 bit fixed point number… just use a bunch of bit shifts and keep track of where the decimal is. Oh… and for Affine… you really don’t need to use floating point. The Affine hardware is 16 bit fixed point, so using a 32 bit fixed point number for the calculations leading up to it is more than enough.

On a side note… I’ve never looked at the gcc output from floating point code… it’s possible that it’s emulating the floating point in fixed point hardware rather than using the floating point instructions, which could explain why it’s so slow (this is how it’s done on fixed point processors). The floating point instructions should take nearly the same amount of time as the fixed point mul/div instructions (8 to 30 clocks compared to 13 for multiply, 44 clocks compared to 38 for divide) although the add and subtract take much longer (9 to 28 clocks compared to 1 for add and 12 to 28 compared to 1 for sub). But there shouldn’t be THAT many instructions that a those few clock cycles pile up… but the software emulation is always REALLY slow. And conversion from floating to fixed and back using the dedicated CPU instruction is also relatively quick (5 to 16 and 9 to 14 cycles).

DogP

jorgeche wrote:

Hehehe… it is my own take on the plants… I really didn’t like the way they worked in the official games (stop coming out when mario is close to the pipe) so I change it the way I want them to work… anyway I can make the bounding box for collision detection to be maybe 4 pixels after the top of its head to not being killed by it when it’s starting to coming out.

Thanks for the feedback!.

jorgeche

Heh, cool… I kinda agree about the plants coming out while you’re on them (keeps you moving), but the biggest problem I had was how the second flower wouldn’t come out of the pipe until you jumped… and by then it’s too late :-P. I had to fake it out by going closer to it in the background, then go to the foreground and jump as it was going down. And then dying after landing on an (almost?) non-existant flower was kinda annoying too ;-). But yeah… it’s looking good!

DogP

I just played through the level… it looks really good, the only thing that got annoying was the plant coming out of the pipe. It would come up while I was on it, I would jump when I thought it was down, but it’d still get me… maybe 1 pixel was still up, and it wouldn’t come up until I’d jump, and then it’d come up on me (the second one was especially annoying). Other than that, it’s really cool!

DogP

Will another month actually help anyone? Doesn’t that usually just cause you to procrastinate more? 😉 Like the 5 months that we’ve had, I worked on it heavy for the first couple weeks, basically stopped working on it after a month, then started back up a couple weeks ago so I can have a finished entry :-P.

If it will help get us more/better entries, I’m definitely up for it… just from past experience working on projects, it seems like extending deadlines usually just delays the work.

DogP

I’ve been working on mine… I’ll definitely have something ready by the deadline, but if you want to bump it back a week or two, that’s fine with me. Is anyone besides Jorgeche and I actually going to release anything? It’s been kinda quiet in here ;-).

Is Fwirt still working on the Yoshi’s Cookie? RunnerPack… anything? DanB??? Anyone coming in with a surprise entry? I was trying to talk Cooler into doing something, but I don’t think it’s gonna happen :-P.

DogP

Looking Good!

DogP

That’s a pretty cool article. BTW, I’ve had several brand new VBs… I sold a couple 6 or 7 years ago, and they didn’t sell for that much (I think $50-$75… they still popped up on ebay every now and then). Then I sold another ~3 years ago and it sold for $250 on ebay… and they actually bought it to play, not to keep unopened (they asked me to test it before shipping). I also sold an unopened Mosaic VB, which sold for ~$350.

But yeah, new systems were never actually sealed.

DogP

You’re thinking too much into this… I just want something so we can all share graphics and so we can just download graphics when we need something rather than having to make/find/rip them. Browsing by thumbnails is really nice so we don’t have to download the whole thing to see if it has what we want.

Being able to update would be nice, but I assume most of the graphics are gonna end up being rips from games, and most of them will be uploaded and never changed again. Doing a complex CVS system would be pointless IMO. I was just saying that the original poster could go back in and replace the original file with an updated one if they wanted to.

Oh… and looking at the localarcade site, it says it runs 4images, which is free for private and non-commercial uses… so it may be worth trying out.

DogP