Thanks… I think it’d be really cool to do a limited cart release, but I don’t know about the legalities of selling something like that, which infringes on Nintendo’s intellectual property. I don’t care about making money off it (in the amount of time I spent on it I could have made a LOT more money than I possibly could by selling it), but I don’t want any legal problems either way. That’d be nice if I could get permission from Nintendo to do it, but I really doubt that’d be possible, and I’d probably just get the response saying “All games must be licensed, but we are no longer licensing games for the Virtual Boy” :(.
If someone made some characters/tracks, I could change them, but IMO it wouldn’t be as good as the Mario Kart theme.
jojobean wrote:
looking at the image further, those stickers look a little aged. also, the fact that the pin is bent cant really be seen as it being fake. he probably got these from somewhere else, but that doesn’t mean they are fakes. even still, thats way too much money for me to spend.
I’m not saying they’re fake because the pin is bent… I know they’re fake, and I’m laughing at him for trying to make the label look aged (to look real), even though the chips were burned and labeled in the last year or so. I’m also laughing at how he can claim they’re worth so much $$$, but not even take care of the chips, although I guess he could always just reburn the chips if the leg breaks off :P.
Thanks for the compliments… yeah… I plan on adding all the different features. I’m currently adding opponents and stuff, but it’s unoptimized, so it’s slow, and not perfect, so I left them out of the released version. Once I get that working, I’ll probably add 2P head to head race (link cable), and then battle mode (linked again, of course), then the full cup races.
I’m not sure about an actual profiler, but you should be able to profile your own code by setting the timer and checking the difference between entry and exit of the function (and storing it in an array somewhere that you can view).
I assume it’s actually because NiCads only have a voltage of 1.2V, which will only output 7.2V (as opposed to 9V from 6 Alkalines)… so even though the batteries may have plenty of charge left, the voltage of a half dead NiCad won’t be able to keep a VB running, when an almost fully dead Alkaline could still run the VB (the voltage regulator probably drops out somewhere between 6 and 7 volts).
Right… Special Cup isn’t available. I was working on adding a 4th track (a Bowser’s castle), but I ran out of time, so I made it so you can only select Mushroom, Flower, or Star cup.
BTW, the speech isn’t samples (since we don’t have a good way to play samples directly), it’s actually a wav that I converted to 4 standard frequency channels (using FFTs), and updated 100 times/sec (with the timer interrupt). I’ve got a lot of tweaking (and some more features) to do on the converter, but for now it works well enough.
It’s not really on topic here, but doing a level editor for JB shouldn’t be too difficult, but it may be kinda time consuming to find where the maps are in the ROM. Of course making a track editor for a game made from scratch is much easier since you know where everything is and what everything does ;).
Yeah, I did a very simple debugger where I had the link interrupt handled with a debugging ISR so I could send a command over the link cable, it’d interrupt the program and either read/write memory, registers, etc. It didn’t have a good interface though (just a command line app that’d ask for the command, ask for the address/reg, then ask for the value to write, or length to read). It worked, and if gdb wasn’t going to be possible I was gonna write my own simple debugger that imports the memory map so you could watch variables and things, but I dropped that idea when I talked to David Tucker and he suggested gdb wouldn’t be too difficult. I figured there’s no point in spending time going to a non-standard and fairly limited debugger when I could instead spend the time to make a backend for gdb and we’d have a really good debugger (with some good available frontends).
The biggest limitation that I came across was that we don’t have a good way to do breakpoints. There’s a TRAP register, which will allow a single breakpoint, but if you want several breakpoints, that’s very difficult because we don’t have either hardware to watch the memory busses and halt on a certain address, or for a software solution we can replace code at a certain address with a jump to our debugging handler which will halt the execution… except with a flash cart, to rewrite a single instruction we need to erase the block, and rewrite the entire block with the modified code. That’s a little time consuming for just a simple operation (probably ~1-2 seconds each time you set or clear a breakpoint)… although it is doable. It’d be much nicer with an SRAM cart (which I’m almost considering building, since that’d be really quick for programming as well).
Thanks… yeah, I took the levels from SNES, but I plan on making an editor so others can make unique tracks, since my time is better spent finishing the game engine, but others who aren’t programmers, but are good at level design could make cool levels.
Do you mean gdb (debugger)? If so, it should be possible, and I was looking at it a while ago (with the USB<->Link cable), but I never got around to really digging into getting it to work. It’s not really high on my priority list right now, but when I get some time I might look into it again. I know David Tucker was very interested in adding gdb support, but I think he’s really busy, so I wouldn’t count on him getting it done soon either.
Yeah, all in one function like that, and cache enabled around the whole thing. Of course I’m doing scaling, rotation, and a tilted view, so mine does a lot more computation than that, but I was able to break down all the variables and move some of the calculations outside of the loop and do minimal expensive calculations inside the loop.
Nope… no ASM (yet). I’m not using the affineSetAll function though… I’ve rolled the initial calculations of the pa, pb, etc into the same loop, taking out parts that are constant throughout the calculation, and enabling cache over the entire loop (the pa, pb, etc calculations take the majority of the time since the affineSetAll stuff can be done w/ just bit shifts and a few additions). I actually have some other speed improvements that I took out while I was debugging some other stuff which I haven’t put back in, since it was working fine, so I’ll put them back soon and see what happens.
Alright… for the people too lazy to burn this to a cart, or those without a cart, here’s a video I posted of it on youtube: http://www.youtube.com/watch?v=k2FKFqO8Kpw .
Oh, and to answer the questions about controls… the right trigger is gas, B the is brake/reverse, the left trigger is jump, the left D-Pad turns, and the right D-Pad changes camera angle.
To get the boost at startup you have to do a burnout while waiting for the light to go “green”. If you do a burnout too long it stalls… and to get the most boost, you want your engine to be at max rev, and you have to let off the brake the moment before the light changes (if you’re holding the brake after the light changes, you spin the tires at the start). It’s a little more complex than most Mario Kart games, but I find them to be too easy, and this way can give you a partial boost if you’re close, but it’s really tough to get the max boost.
Thanks for the comments… yeah, the player 3D effect isn’t perfect on all characters because I’m using kart images from the SNES SMK, and to get the 3D effect I’m using images of a turn slightly off center on each eye, but the original images aren’t necessarily good for stereoscopic viewing. I think it looked better than 2D cutouts like I originally was using though, and I plan on tweaking/redoing the graphics for the characters in the future.
The affine ground and parallax are probably not perfect, and I plan on checking over it again in the future, but especially when a map is rotated at intermediate angles there is inherently less precision in the affine tables. Of course imperfections are more visible with textured ground rather than plain ground, but tracks like the Ghost House are much cooler looking than the untextured track in Mario Circuit IMO.
Overall, the minor imperfections weren’t worth spending too much time on though, since the idea is to be racing rather than staring at the track ;-). I thought it was more important (and fun) to add some interesting things like having Lakitu, background music, speech, sound effects, rotating camera, etc.
jorgeche wrote:
Hi, here is the latest build which is now running a lot better on the real machine (due to changing all math from float to fixed point, thanks guys) and it haven’t crashed on it too.
jorgeche
Is this the last version, or is another one coming?
