I don’t remember exactly the reason I was told, but IIRC it has something to do with typing ‘n’s on JP keyboards… I think you have to hit the key twice or something. There’s another spot where it’s mistyped as Ninntenndo, so that may be the reason, or maybe their keyboard had a sticky n key :-P.
From those, you should realize that the code you put in is a Pseudo-Random Number Generator (PRNG). What that means is that if you run this without a random seed, or initializing number, your results will be the same every time. With a different seed, the PRNG will create a different sequence, and therefore your octopus will move differently.
With a random seed, there will be no way to know which sequence is being generated, and will seem random (assuming you have enough bits for the seed). The more bits you have in your seed, the more possible sequences you can have (i.e. if you only have 1 bit for the seed, it will select one of two sequences).
Lets take a very simple example.
Random output = (current value * 3) + 1
current value = 0 at startup (or seeded with 0)
random sequence = {1, 4, 13, 40, …}
This will be the same sequence every time.
Now if you seed it with 2, it’ll be: {7, 22, 67, …}.
A PRNG is just a more complex equation, usually creating a more evenly distributed sequence.
So, if you have a variable that you constantly increment in your title screen loop, it’ll update so fast that the person won’t be able to press start at a precise enough time to select the same random sequence. That counter number will be your seed, and relatively random.
I don’t have time to try to figure out exactly what the random function does, but I see on line 445, you shouldn’t have the ; after the for line… it should be:
for(m=0;m<256;m++)
t[m]=KISS;
I assume that loop initializes your random table, but as you have it in your code, your entire table is uninitialized, and you're clobbering the next address in memory, which is likely n. But what are you using to seed the generator? Without seeding, it'll be the same sequence every time.
It’s been a while since I’ve done the oven method, but IIRC it wasn’t very long… just keep watching, and if the cable looks like it’s getting too hot (starting to curl or anything else bad), then pull them. On my howto on my site: http://www.projectvb.com/displayfix.html#Oven I said a couple minutes, which sounds about right.
Well, there’s lots of pseudo random number functions out there, but you need to “seed” them with something that’s truely random for it to work well. Basically, if you have the same seed, you’ll get the same sequence, so the idea is that you need to seed it with something that can’t be purposely reproduced, then the sequence will be different every time.
One common and easy to use seed is while waiting for the user to press start, have a counter running. The counter will run REALLY fast (probably somewhere around 1 million times/sec), so it’d be very difficult for someone to time their keypress to get the same predicted sequence. Of course you have to make sure you force them to wait (if someone’s holding start, wait for them to release it before counting and accepting a keypress). This is important since if they hold the start button and you allow that, you’ll get a count of 0.
I don’t have any good links for a pseudo random number generator off hand, but you can do a search on google, or just come up with something “good enough”, and just call it as a function, then when you decide you want something better, just replace that function.
A crappy method, but very easy to visualize and implement for a temporary PRNG is the middle-square method. Just take your first number, square it, then take the middle section. It’s easiest to visualize as hex… your first number is 4 hex digits, square it and you get 8 hex digits, return the middle 4 hex digits (shift right 8 bits, AND 0xFFFF). That number is your random number and input to the next random. That can easily get stuck on numbers (like 0000), which have the same output, so you should check that the previous value was different than the current value, and if not, do something (like add your original number, or multiply the previous by the original, or whatever you want).
Or… just do a search on google, you’ll find plenty of examples… probably many that you can just copy/paste. The only specific implementation is the seeding… most PC based ones use a clock or something similar… the VB doesn’t really have anything like that easily accessible, so the counter on human input works pretty well.
I didn’t look at the source code, but my first guess is that it looks like the sub image you put in with the treasure chest is smaller than the image you used to have in its own charseg. Since your collision detection is hardcoded for the size and shape of the sub, if you’re gonna change the sub, you’ll need to change the collision detection. If you leave the sub the same size/shape, you should be fine.
Well, there’s no reason they all need to be in different char segments. A really easy modification would be to move the player and treasure chest into the same charseg, and the octopus could be in that same one as well.
For ease of use, you can make them all in their own world, which would be a limiting factor, but you have 32 of them… there’s no reason you need individual charsegs, and that definitely shouldn’t be your limiting factor.
I assume you’re using VIDE to make your graphics? If so, just merge your graphics for the sub, treasure chest, and octopus into the same bmp, then convert. To draw it, just change the MX and MY value from 0, 0 to whatever the offset in the bmp is.
BTW, that speed is better IMO. Oh, and that’s some major abuse of the C language :P.
Edit: Something that would be pretty cool if you added would be moving obstacles (walls, mines, etc)… either free randomly floating obstacles, walls that bounce back in a linear path, or a rotating bar (like the fire bars in Bowser’s Castles in Mario Bros). The appearing/disappearing walls are definitely the most interesting part of your game, but you can just stall in front of them until you get the timing right… something that forces you to keep moving along would make it more exciting.
Cool… looking good. Do you plan on making any game changes? Like adding enemies, floating mines, current, or anything? How about a speed setting? I haven’t tried it on hardware, but it seems pretty slow (and therefore easy) in RB.
Also, I noticed after you die, you have two GOSUB logos on the title screen.
I believe it’s called an Infinity Mirror. You basically have a mirror in the back with a two-way mirror facing inward… then some sort of lighted object in between. The two-way mirror reflects some of the light back to the mirror and lets some through, which gives it the “infinity” look.
Is that supposed to be a threat? Why do any of us care what you do with your VB? There’s a chunk of moldy cheese in my fridge that I’ll be tossing out on trash day (which is also a few days away for me). If you don’t have much money, why not put it on ebay and get a few bucks out of it?
Not sure if it helps you any, but I’ve got my site back online… sorta (it’s supposed to be up, but it seems like my new host is down at the moment 😛 ): http://www.projectvb.com/ .
I changed ISPs, and my new one only gave me 10MB, so I decided to find a new free host, and saw projectvb.com was available, so I figured I’d just buy that domain while I was changing things. The page is currently identical to the old one (and still has my old email address), so I’ll be updating it once I get everything figured out.
I have no idea about the technical details of how it’s handled in gccvb, so I don’t think I’ll be of help… I have wondered whether they were supported though. So if you can get them to work, that’d be great.
One thing you might want to look at is: http://www.vr32.de/modules/newbb/viewtopic.php?topic_id=3391&forum=2 … the only problem is that it’s written in assembly with just a c prototype to make it callable from c, so it probably won’t tell you much except maybe help with how the assembly output _should_ look.
You might also want to try emailing David Tucker… he may know something about how gccvb handles that kinda stuff.
Yeah… if there’s no news to report, I’m glad there’s no news reported. Most of the time, the news they report is actually worth reading, and I take a few minutes to read it… and the few forum posts are usually worthwhile to at least look at.
I appreciate the PVB guys keeping dedicated to the VB… of course it’d be better for them to expand to millions of members and throw ads all over the pages, but since they don’t, I feel like I can call this home, and actually pay attention to anything that does get posted. When I have to sift through tons of junk to get the good stuff, I lose interest. How it is now, I can drop by, get my VB fix, and move on. If I want to talk about video games in general, I can go to one of the many other general VG related sites.
dasi wrote:
I’ve just noticed the 9V 500mA AC adaptor I’ve been using for the last 18 months is labeled AC – AC, so it’s outputting 9V AC, which is bad, right?
I wouldn’t have expected 9V AC to work, but that’s cool that it does. There’s a power regulator on the motherboard, but it’s supposed to be a DC to DC regulator. As HT said, he didn’t fry his by hooking power up backwards, so it must have protection for reverse polarity (probably to prevent incorrectly installed batteries from frying it), and low voltage won’t hurt anything (like dead battery). But with 9VAC, you’re only getting power about 1/4 of the time, so the large caps on the motherboard must smooth that out well enough.
Do you have batteries or an AC adapter? If batteries, did you try brand new ones? If AC adapter, did you test the voltage? The vibrating is the mirrors moving which means you have some power, but not necessarily enough to run the game. Also, note that a lot of games take some time to start before outputting any sound (warning screens and stuff), so if your displays are dead (by far the most common problem), you may have to keep pressing start for 30 seconds or so before you actually hear any intro sounds.
Yup… that’s basically the same as the oven method, except using a heat gun as the heat source. You gotta be really careful with those though because it’ll easily curl the cable if you get it too hot.
Can you elaborate? How is the method different than before? I ran the demo and I see the center looks the best and both edges are equally somewhat bad, compared to the old ones where the left looks good and gets progressively worse as it goes right. Does it work similar to how I suggested by computing the center, then subtracting the half the screen width times the incremental part?
I guess I should change my Kart code to look better, so I’d just like to make sure I understand what I should change, since I’ve done a bunch of optimizing and can’t really just copy/paste other code.
Hmm… now that I think about it, it’s probably possible to get it looking better by doing multiple Affines for smaller chunks of the screen, although of course that’d be a little more processing, code, and memory… but you could get it looking nearly perfect across the entire screen that way (3 would probably look really good, 6 would probably be nearly perfect). Just compute the offsets at multiple places across the screen in higher precision, then round to the lower precision at the centers of each Affine world, and subtract half the width times dx and dy of lower precision for the start of each. Once again, it’s just in head, so there may be some reason it won’t work… but I think it’d work great. You might use too much memory, so maybe just do that for the closest 50 lines or so, since you wouldn’t notice it on the distant ones.
I think this should fix the problem. However, copying vb.ld to /usr/local/v810/lib/ like it says in build.txt doesn’t override the default script.
Just wanted to let you know I ran across this problem again today and this change does seem to fix the problem (it fails w/o and works w/… as long as it doesn’t just make it break somewhere else 😛 ). Like you said, copying the vb.ld to /usr/local/v810/lib/ doesn’t make the change, but adding that into v810.sc and recompiling fixed it (or you can manually specify the vb.ld in your build script as RunnerPack said).
