Posts for Kuwaga

Experienced Forum User
Joined: 10/20/2006
Posts: 1248
Ocarina of Time: No doors? It's alright. The execution isn't exactly optimal, but given the arbitrariness of this category, I think it should be seen more as a playaround anyway. I'm kind of displeased to see Ganondoor being used though. Sure, you didn't open it, but you've still "ganondoored" in no doors, which kind of leaves a sour taste in my mouth. Maybe we could just rename this particular instance of the glitch into "Ganonnodoor" because you really aren't using the door but the warp behind it? Still, the fact remains that you got uncomfortably close to a door. I really hope to see the route being improved in the future, so it can keep even farther away from those horrible things. Also, I was extremely disturbed to see you passing through many GATES. They're clearly a lesser evil, it was Zelda who opened them, and the goal doesn't explicitely state to avoid them, but why not simply choose the objectively better goal of avoiding those too? Anyway, that's just my personal take on it. Voting yes for the best ground jump ever seen in an OoT TAS, for not getting bombs, for pressing A to quickgrab ledges, and for hooking the crap out of Ganon.
Post subject: Re: How to determine the formula for a random number generator?
Experienced Forum User
Joined: 10/20/2006
Posts: 1248
In practice, them using LCG very often means you're going to have an incredibly easy time figuring out the algorithm. Most of the time, you don't even need to disassemble those. For LCG, the formula for advancing through seeds is (oldSeed*x+y)%z. (Will keep calling each iteration "seed", even though that might not be technically correct) Most of the time, the %z part is just dropping the highest bits and will occur naturally in older systems. F.e., z would be 65536 for 16bit values. 1) Find the address they store the last seed at 2) Find a way to advance this seed by exactly one iteration. 3) Set this address to 0, advance once. (0*x+y)%z will give you y. 4) Set this address to 1, advance once. (1*x+y)%z will either give you x+y or (x+y)%z (They might also use XOR) And you're usually just about done at this point. When analyzing the RNG of older games, I usually first try this procedure. Only if it fails, I'll disassemble. It can often save you lots of time. (If you already have a disassembler open, it might still be faster to just disassemble though) 5) For each random event, they'll usually take either a portion of the last seed or the seed they have just advanced to (they'll either advance the seed before or after getting the actual random number they'll use), and take that portion % the number of possible outcomes for the random event in question. By "portion", I mean any number of consecutive bits of the seed. You should be able to work things out from there. Maybe without disassembling again. (Though disassembling would generally save time with this step) Please go easy on me when pointing out everything that's wrong with this post. I know straight-up disassembling is actually the proper way, and I don't recommend anyone should follow my advice.
Experienced Forum User
Joined: 10/20/2006
Posts: 1248
Kuwaga wrote:
I think this mentality of "if I want something, I need to cry very loudly and shout at people higher up till they do something about it" is a serious problem with our modern society as a whole. If you want things to change, just do it. Offer something instead of demanding something. That's just my advice, you are free to completely disagree and call me an idiot, or ignore me, or whatever. There'll be no hard feeling from my side.
Dyshonest wrote:
This, in turn though, makes authoritative figures/higher-ups ultimately pointless if everything boils down to "do it yourself" instead of the people above you... uh, doing their jobs.
And that would be a problem to whom? To you? You can't do any part of the work yourself because it's unfortunately theirs, so you have to loudly remind them of it till they do something instead? In that case, you are of course free to try it and see how far it gets you. You can't exactly threaten them with a labor strike here. What exactly is their job anyway and what exactly is yours? We all might have different opinions on this. You think the job of the admins here is to please you, or every other little minority here? Well, I think they'd disagree. Who are you to tell them what their job is? If you completely refute this post and I won't argue against it, it means I'll have silently admitted defeat.
Experienced Forum User
Joined: 10/20/2006
Posts: 1248
Here's a suggestion to people like xnamkcor and Dyshonest (the order I named them in is arbitrary, not in order of importance). If you want to have a list of all the TASes for hacks that produce somewhat entertaining runs, and meet a minimal standard of quality, just compile such a list yourself. Then put it somewhere on these forums. And watch what happens. What you are doing now is arguing that somebody else should do extra work that they think is not necessary. In fact, they even think doing that extra work would make things worse. Are you seriously trying to convince them through your brilliant arguments to do that kind of work anyway? Why not do it yourselves, if you think it'd make the world a better place? Got better things to do? Well, so do the people you are demanding that work from. [URL=http://tasvideos.org/Movies/GruefoodDelight.html]Gruefood Delight[/URL] started as a list of movies compiled by (mostly) [URL=http://tasvideos.org/forum/profile.php?mode=viewprofile&u=2736]alden[/URL]. He wanted there to be a list of notable rejected runs, so he made one. You are free to do the same. I think this mentality of "if I want something, I need to cry very loudly and shout at people higher up till they do something about it" is a serious problem with our modern society as a whole. If you want things to change, just do it. Offer something instead of demanding something. That's just my advice, you are free to completely disagree and call me an idiot, or ignore me, or whatever. There'll be no hard feeling from my side.
Experienced Forum User
Joined: 10/20/2006
Posts: 1248
All kinds of graphical effects, like what you see behind your cart, enemy AI, and I don't know what else. I've spent very little time, like I've said. But it's a lot per frame, and that kind of makes it look to me like predicting an RNG roll several frames ahead might not be feasible. Drifiting and all that should influence the RNG because it'll pull a different amount of numbers for graphical effects.
Experienced Forum User
Joined: 10/20/2006
Posts: 1248
JSmith wrote:
So what you actually need is a count of how many rng numbers you are consuming during the item spin [...]
Scepheo wrote:
None. The item spin just loops through all possible items in order. There appears to be very little in the game that depends on the rng, which is probably why the existing one is so odd: it'd probably be noticeable otherwise (same sequences of items).
I've only spent very little time so far, but this is definitely not correct. At least over a hundred numbers are generated every single frame in a race.
Experienced Forum User
Joined: 10/20/2006
Posts: 1248
Yes, using emulators in recompiler mode, if they have one, already makes ACE not work most of the time. Basically, emulators can gain speed from not reading the original byte code at all while running the game, but converting it to x86/x64 machine code only once, then keep executing that converted code only. So to detect ACE, just have it run in recompiler mode and watch it not work. ;p Edit: That's a description of a very crude recompiler mode. A more advanced one would detect self-modifying code and adapt, but at the cost of speed, which was the reason to go recompiler mode in the first place. So that arguably defeats part of the point. I just wanted to point out that these kinds of ideas of detecting ACE are not entirely new at all.
Experienced Forum User
Joined: 10/20/2006
Posts: 1248
I could probably work something out, but I'd rather not given that somebody else has already spent a lot of time and effort on this.
Experienced Forum User
Joined: 10/20/2006
Posts: 1248
Yes, a Gameshark code that changes the colors can be made. No surprise there. If you just want to look at them, manually changing the values in RAM should be easy enough though. Scroll down to Pocket Cucco, and a bit further to Colored Gauntlets [URL=http://www.zeldaspeedruns.com/oot/ba/reverse-bottle-adventure]here[/URL] Creating such a GS code (that doesn't mess up parts of your inventory) would be pretty decently difficult, and considering how little use there'd be for it, I really wonder if it's worth the effort though.
Experienced Forum User
Joined: 10/20/2006
Posts: 1248
Unless said overwrote/garbled memory is being actively executed the fact that it was corrupted will not be known.
Changing the words in the book in my example makes you read out something different. It's not being executed. You don't do what the book tells you to. Yet I can hear you say something out of the ordinary. So the fact that the words in that book have been changed can be known. If this isn't clear to you, I cannot help.
I am doing quite well, Freud, but thank you for your brilliant and stunning analysis of a person you've never talked to prior.
This is not meant to be a diagnosis, but as a provocation to reflect on your way of thinking.
I take it you aren't interested in changing your way of thinking. That is fine. It was meant as an offer.
Experienced Forum User
Joined: 10/20/2006
Posts: 1248
I don't mind being trolled every now and then. I also don't mind being wrong. The spirit in which your words were written might sometimes be more important than how much truth lies in them. Words can never perfectly describe anything, so they're always wrong to an extent. That's why it's so easy to infinitely extend an argument, because it's so easy to find aspects of un-truths within somebody's words. If I minded being wrong, I'd either never speak a single word or speak as many words as I can to make sure I got the last one that hasn't been exposed yet.
Experienced Forum User
Joined: 10/20/2006
Posts: 1248
Reading and utilizing memory is not the same as executing it. 01 Open your book at page 55 02 Read out the topleft word Slight memory corruption might change the topleft word (heck you might even be able to change it through completely regular gameplay or a minor glitch). By changing that word, it'd make you read out something different. That's not executing the changed memory though. ACE starts when you manage to manipulate the list of instructions itself instead. 01 Open your book at page 55 02 Tear out the page and eat it This is the beginning of ACE. You change the list of instructions itself. Total control is when you can manage something like this: 01 Open your book at page 55 02 While your book is opened at page 55 03 Do exactly what I say (f.e. executing controller input) Then, "whatever I say" can become something like you should learn to play the piano. And then I'd make you play some nice songs. Can you see that by just regular memory manipulation something like this isn't possible at all? Even if you change all the words in all the books, it can just make that person read out a different word. ACE is on another level. If you want to argue slippery slopes, then, as others have pointed out, you could just extend the slippery slope to show why it's ridiculous. 1) Memory manipulation can sometimes lead to ACE, so there should be no difference. If a run manipulates memory, it might as well do ACE and reach the credits. It's basically the same thing, just the one time you use memory manipulation to its fullest capacity, and the other time you don't. 2) Minor glitching can sometimes lead to memory manipulation, so there should be no difference. If a run does minor glitching, it might as well do memory manipulation and accomplish ACE. It's basically the same thing, just the one time you use minor glitching to its fullest capacity, and the other time you don't. 3) Controller inputs can sometimes lead to minor glitching, so there should be no difference. If a run does controller inputs, it might as well do minor glitching and accomplish memory manipulation. It's basically the same thing, just the one time you use controller inputs to their fullest capacity, and the other time you don't. "But controller inputs were intended by the developers and the rest wasn't" We all already agree on this. However, it's not possible to find out what exactly was intended by some developer and what wasn't. It's difficult to know where to draw the line. That's why there are so few "glitchless" runs. In determining where ACE really starts, there can also be grey areas, and whenever those come up, you can count on there being some discussion about them. We already know there can be grey areas sometimes. However, even with minor grey areas, it should be easy to see which category to put a run into. Is it mostly glitchless, but allows some glitch that's very hard or impossible to avoid? Clearly in the glitchless category. Does the game execute some sprite memory as code at some point that's unavoidable? The devs just never noticed because it usually doesn't mess anything up? Well, you could argue that's a grey area for ACE, as the sprites could easily be manipulated. However, there could be a run that's consciously avoiding that, to show off other glitches that many people would like to see. Put it in the ACE category? Reject it? What for if it's unavoidable? If that still doesn't help, reading [URL=http://en.wikipedia.org/wiki/Splitting_%28psychology%29]this[/URL] might help, but it probably won't. You might feel the need to seperate runs entirely into two seperate categories, 100% glitch free and 100% glitched. That would make you feel at ease, before that's done, something would never seem quite right or slightly awkward to you. This is not meant to be a diagnosis, but as a provocation to reflect on your way of thinking.
Experienced Forum User
Joined: 10/20/2006
Posts: 1248
That's pretty great! I haven't had to use that approach yet, but it seems to be a great idea! Usually, I just patch out the lines that do the reads/writes I'm not interested in, so I can use Nemu's break on read/write feature to find what I'm looking for. Works fine most of the time, though sometimes it doesn't do the trick and I need to find a workaround. Also, I haven't been able to find a memory address that corresponds to PC in my version of PJ64 (maybe haven't looked hard enough), but the RA register is at Project64.exe+D53E0 for me. If it isn't at that address for you, searching for the K0 register in memory should be easy (search for A430000C). The RA register should then be at the address of K0 + 0x28. Looking at that one could often save you the stepping through the x86 assembler code part. (The code you're looking for should either be inside the preceding function call or immediately afterwards)
Experienced Forum User
Joined: 10/20/2006
Posts: 1248
SeanSullivan86 wrote:
I guess I'll try looking harder for a relevant memory address. Haven't tried too hard yet. I just realized I can't even produce this behavior in Nemu. I use bizhawk for finding memory addresses usually... and it's easy to produce the behavior there. I guess Nemu's input plugin is converting my left/right key presses into analog movements differently than bizhawk does.
Ah, yes, Nemu is horrible in that regard. Maybe reconfiguring the input plugin would help. Else, you could maybe manually modify the address that indicates how far to the left or right you are pressing your analog stick. It should be closeby to Gameshark enabler codes in memory ("D0xxxxxx xxxx" or "D1xxxxxx xxxx", checking for whether you pressed a certain button).
SeanSullivan86 wrote:
I still think dumping all the addresses of the instructions executed over a period of time would be a helpful thing.
Maybe. Though I fear it would be so much data that browsing through it would almost always be slower than other approaches. It's not impossible to add that kind of functionality. Seems like something I could do with a very silly and dirty hack if I took the time, but I'm not convinced it'd be very beneficial yet. I agree that better debugging tools in general would be awesome to have for N64, which is why I started working on some very slowly. But that project is currently on hold for at least another month.
Experienced Forum User
Joined: 10/20/2006
Posts: 1248
SeanSullivan86 wrote:
I want to investigate some of the game mechanics to see under what conditions they occur. For example, in 150cc mode, if you correct your steering too much, you spin out.
Find an address that indicates whether you are currently spinning out or not. Correct your steering too much with a breakpoint on write to that address. Then you should be inside some function related to it. It's very likely that it's not the actual function you are looking for though, you probably want to find some function that calls it. To find out what called the function you are currently in, sometimes all that needs to be done is to look at the RA register and subtract 8 to find the line of code that called it. If it instead leads to another function called from within the function you are currently in, the RA value you are looking for should be somewhere on the stack (SP plus or minus something, depending on the game). Alternatively, and very often faster, you could just find the end of that function, set a breakpoint there (click the grey area left of that line of code) and see where it returns to. Once you got the line that calls the function you're currently in, set a breakpoint there, repeat the process (i.e. load a save state, steer too much, this time the game should halt at the breakpoint you've manually set before the break on write). That way you can manually step through function calls backwards. Though for this particular case, it would probably be better to search for a value that increases (or decreases) (might even be a float) as you keep correcting your steering a lot. Then set a breakpoint on read and hope to find a branching command afterwards that compares it against some value depending on the mode you are currently in. If you're unlucky, this branch is inside another function that gets called by the function you are currently in. In that case, coming up with a creative solution might be faster than stepping through all those functions (that's assuming there'd be a lot of them). That's some general ideas. Edit:
SeanSullivan86 wrote:
I'm not particularly fast at looking at a bunch of instructions and knowing immediately what the purpose of the code is.
Find the start of that function and modify the first line to JR, the second to NOP. Or find the line that calls this function and change the JAL there to NOP. That way you patch the function (or that particular function call) out of the game. Very often, this leads to quick results, as it'd be obvious what kind of behavior is now missing from the game. To quickly patch a line of code, let's say you want to change 80034bac to JR, manually add a 4 byte value to your list of RAM values that corresponds to that line of code. Then freeze it to 03e00008 (that's JR RA, NOP would be 00000000). If you let your "Commands" window in Nemu refresh now (f.e. by using up or down arrow buttons), the code should appear to be updated already. However, Nemu won't execute it as that, as it executes most code from a buffer. Load a save state and your changes will be functional. Note: Be careful not to overwrite your save state after patching a line of code. That would lead to that line of code being permanently patched from that save state onwards. Another trick to speed up your deciphering of code (sometimes): If you aren't interested in all of the code within a certain code segment, but just what happens to a certain value, see which register it gets loaded into, set a break on register change, hit "Go", and you'll hit the next line that uses that value.
Experienced Forum User
Joined: 10/20/2006
Posts: 1248
I started writing a lengthy reply that seemed to turn into a rushed general tutorial on how I do debugging with Nemu. I guess that's probably not what you are looking for. Why don't you tell us the real problem you are trying to solve? (What's the type of situation where you would want to use this approach?) It should help me come up with a better reply. I can tell you this much already though: Nemu is probably the N64 emulator with the best debugging tools you will find. What you want to do here is indeed possible, but it can't be fully automated as of yet (not that I know of), so it'd be quite laborious. I think it's pretty unlikely to be the best solution to the [URL=http://blogs.msdn.com/b/oldnewthing/archive/2011/11/04/10233798.aspx]real problem[/URL] you have.* Also, it takes quite a while to explain all the details and special cases of the approach I had in mind (which is why my original reply started to blow up to unreasonable lengths). Opcode breaks at JAL and JALR will let you see all function calls, and you could manually log them. I don't recommend this though. You'd be surprised at how many there are, and every single loop over a function call will cause you lots of trouble. *) That link is not meant to be condescending, it's just an example of a situation that illustrates why stating the real problem you are trying to solve might be helpful when asking questions.
Experienced Forum User
Joined: 10/20/2006
Posts: 1248
Find a game where the Japanese intro screen lasts a few frames longer / shorter than the US one (or take PAL if you must). I agree it would be kind of cool to see. The reason we don't see more "multiple games at once" runs is because no emulator that I know of has built in tools to create those runs. I remember modding Gens years ago (even though it had been above my level of competence at the time), so I could run multiple instances in sync, but then lost the code halfway through. Warp, you are a professional coder and want to see runs of that kind. Why not add such a feature to an emulator of your choice? (Bizhawk?) It shouldn't even be that difficult, right? Have a special emulation mode where: 1) Instances of the emulator that are open are able to find/see each other. 2) Input is shared between them. 3) Each is only able to advance to the next frame when all emulators are ready (have agreed to use the same input for the next frame). 4) Save state files must add an additional pre- or post-fix so they don't overlap. Of course you might be able to think of an even better way to implement it. It probably could be done with LUA scripts (since they can use dlls, so everything is possible), but if it was actually part of the emulator's menu, I think more people would find and use that feature. Somehow, I expect to be met with disagreement.
Experienced Forum User
Joined: 10/20/2006
Posts: 1248
I think you'll be laughing at how stupid my level 13 solution is. It's a minimal effort solution, basically the first thing I tried. "I don't feel like using my brain, let's see if this works!" var r = Math.random() *10; if (r < 1) me.move('up'); else if (r<3) me.move('down'); else if (r<5) me.move('left'); else me.move('right'); //Hit "Execute" till a level gets generated that looks like it could solve it //Then run from left to right, eating popcorn with the other hand
Experienced Forum User
Joined: 10/20/2006
Posts: 1248
It might be that Nintendo won't allow the streaming of SSBM at Evo 2014. In that case, maybe this video will make their decision easier to understand for you. Edit: Nevermind. It's just been as good as confirmed that they'll allow it. Link to video Also, if you are looking for a way to waste time, you could watch this documentary. Link to video
Experienced Forum User
Joined: 10/20/2006
Posts: 1248
OmnipotentEntity wrote:
Oh wow, really? A pedantic absurdist?
Pedantic, I'll take. I was pedantic about it because your post came directly after mine and contradicted it. I am sorry about that. I wonder what's absurd about what I've said though. Newtonian physics are an abstraction that works very well, testable, makes thousands of predictions. Some people take that to mean that anything it claims is truly true, not just within the system. It's suddenly self-evident, right? That way of thinking is what's absurd to me. To me, it just means Newtonian physics is a very powerful tool, an abstraction that works. In case it ever doesn't work for something, no problem, we'll work out something that does. (And we did.) Do closed systems truly exist? Besides the point, we can just assume they do, and create a powerful tool. Make assumptions, create a system within which we can make predictions. How, if it made those assumptions, is it then absurd to question whether it's truly true? Shouldn't that be the default stance? Of course, it's annoying if somebody brings that up in discussions all the time, but I feel like it was directly relevant to Warp's question. Not to offend you, but I really sometimes feel like science is some people's religion. Saying the number 1 truly exists outside of mathematics is as absurd to me as saying potential energy truly exists outside of physics, which I took was what you meant to say. You really said it wasn't just an abstract concept. Anyway, I'm starting to derail. I'll stop posting again. Sorry if there have been any misunderstandings.
Experienced Forum User
Joined: 10/20/2006
Posts: 1248
OmnipotentEntity wrote:
Potential Energy is not an abstract concept. ... This is a simplification, of course. But I just wanted to fight the notion that potential energy only makes sense when you relate it to something else, and that it's only an abstract concept.
It isn't just an abstract concept? How can that be shown? Any theorem must be based on axioms, which can't be proven from within the system. How can any knowledge at all ever be anything more than an abstraction? You are saying that it truly exists, right? Not that it truly exists within the framework of physics. I wonder how that can be done.
Experienced Forum User
Joined: 10/20/2006
Posts: 1248
First of all, I'd like to express that I have no idea what I'm talking about. Alright. My extremely naive notion of what potential energy is is that it's energy that had to have been put into a thing for it to exist in its present form. At any point in time, the whole object/body could disintegrate (usually by interacting with much more disorderly things) releasing all of that energy again (usually as warmth, which I naively think of as just "random" chaotic movement of particles). So within my naive logic, potential energy is visible by order: a fixed position relative to something, a fixed shape, a mass; rather than chaos: constant change, only measurable by its impact on things that aren't in chaos. Pretty sure that's at least partially wrong though, if not completely, but I'll state it as naively as that. I feel like almost any interpretation of physical equations should be at least partially wrong anyway. How to measure it then, it depends. By converting it all into warmth maybe, splitting every atom if you want to go to extremes. As you are familiar with quantum physics, the idea that measuring something might have a radical impact on the thing you are measuring might not be foreign. According to my naive logic, to measure the potential energy, you'd have to convert it all into other forms of energy. Why can potential energy exist at all, I think of it as a system being temporarily stuck in a local minimum of energy efficiency. To move it into a truly more efficient state, it has to be forced out of that minimum first. Feel free to tell me why I'm completely wrong, and why I shouldn't think of potential energy as that. I honestly think that even concepts such as "mass" are just necessary (for us) analogies and abstractions and don't truly exist either, so all our interpretations of the world would have to be fundamentally flawed at some level anyway. As long as you talk about concepts within a certain framework, they all make perfect sense, what they truly mean is often beyond our grasp. I don't even know what 1+1=2 truly means outside of mathematics. It seems to presuppose that something can be quantified. Can anything be truly quantified, or is it just a way of thinking about things, a helpful abstraction? I don't know. Gödel's incompleteness theorems are why I see science as a tool rather than as truth.
Experienced Forum User
Joined: 10/20/2006
Posts: 1248
You must be thinking very highly of your coding skills if you think an engine you write all by yourself, even though it seems you hardly have any experience, is going to be more "stable" than well tested engines that many experienced people have been working on. I'm not suggesting you should use one, but your reasoning for why you don't seems questionable. Especially, since the very thing you are afraid of happening with premade engines is already happening in yours (i.e. randomly falling through the floor etc). Thanks @Derakon for adding his input, I agree. Somehow I got the impression that henke was trying to create a widely reusable, generic platforming engine. If you got the whole game planned out already, you can take many shortcuts. Although, I'd at least add comments inside the code that express the silent assumptions that it makes. (f.e. the player's speed can't exceed M, so maxSpeed must never be changed by anybody touching the code, and that walls can't be thinner than N) As a project grows, even if you are the only coder, I think you'll come to find these kinds of comments helpful. I still cringe at changing the player's coordinates before applying collision detection (I know you haven't been arguing against that). I think it's very bad practice. Since henke hasn't replied, I'll assume the worst case that he silently disagrees. Maybe this will make it more apparent why it's such a red flag to me. I read the code somewhat like this:
      protected function xMovement():void {
         horizontalControl();
         
         //cap the speed
         if(player.xSpeed>maxXSpeed) { player.xSpeed=maxXSpeed; }
         else if(player.xSpeed< -maxXSpeed) { player.xSpeed= -maxXSpeed; }
         
         if(autoMirror) {
            if(player.xSpeed<0>0) {
               player.char.scaleX=1;
            }
         }
         
         player.x+=player.xSpeed;
         //WARNING! Under no circumstances must any other method be called between these lines
         //player.x may not actually be the player's x until applyCollisions returns!
         player.applyCollisions(true,false);
      } 
      ....
      playerInternal function applyCollisions(xDir:Boolean,yDir:Boolean):void {
         //WARNING! Every method called by applyCollisions must not assume that player.x is actually the player's x or that player.y is actually the player's y
         //It might be that they indicate the player is inside a wall even though he/she/it actually isn't 
It just begs for it to eventually introduce bugs. For example, you can't even call player.isUnderWater()* which returns true if player.x and player.y correspond to coordinates that are under water during applyCollisions, unless the wall he/she/it might be temporarily inside of knows it's an underwater wall. (An exception is if water can only be at sea level and there can be no individual pools of water above that, but I hope you get the point). Do yourself a favor and don't write code like this. If you do stuff like that in more than one place, chances are you're going to have a very hard time. I think that's all I'll have to say. Good luck. *) Of course this method shouldn't really be part of the player object anyway. Just for the sake of illustration.
Experienced Forum User
Joined: 10/20/2006
Posts: 1248
You're trying to apply collision detection after the player object has already moved. I don't recommend that. First of all, you could get a speed that's higher than a wall is thick that way, and no collision wouldl ever be detected, as the player would have already successfully passed through the wall. And just overall, it's very easy to write buggy code that way. Check for collision in the area between the player's x and the new would-be-x, only then make the player actually move. Rewriting the whole collision code might not be a bad idea. Keep the old code save, and rewrite it line by line, using the old code as a guide. That forces you to think about every single line and you're almost sure to find an improvement or two. For complex movements (let's say there's also wind and whatever else to deal with), a common approach is to have a lazily named variable vecx, that's either positive or negative. You add up vecx=wind.xspeed+player.xspeed (if they are all signed), then check for collision which would adjust vecx and the speed (maybe there can be bouncy walls or whatever, or otherwise just set it to move straight into the wall and no further), only then change the player's x by simply adding vecx. Ideally, you'd pass vecx and vexy at the same time and pretend the player moves on a straight line along them. The overall idea of that approach is to move the whole system from one state that makes sense, into another state that makes sense. Never apply changes in hopes that you can still partially reverse them with a complex chain of methods. The "no problem, I'll fix it later" approach can quickly get out of hands. Applies to way more than just collision detection. If there's still a bug after all of that, and you can't find it, make the game print out (or otherwise log) all player.x, and vecx, or whatever else you need to print out until you find the actual mistake. Set player.x and player.xspeed in such a way that it pinpoints down the problem, read the code, think to yourself "vecx should be this right now", then print it out to check if that's actually true. In case it is, you know the mistake is probably somewhere after that line. Maybe there are better ways to debug, I haven't had any experience with flash at all. Another thing I've noticed: Don't name a method checkWall returning a boolean, if it does more than just checking if there's a wall. Yours seems to modify member variables.
Post subject: Re: Accidental eBay Sell; Going with it
Experienced Forum User
Joined: 10/20/2006
Posts: 1248
L-Spiro wrote:
And some of you may be interested in a Japanese Nintendo Wii console with 3 bundled games (none of which require Japanese language knowledge to play): http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=281237102608
"Japanese Nintendo Wii console" - OK, I get that Nintendo is a Japanese company, which makes the Wii a Japanese product. I still think "Japanese Nintendo Wii console" is a pretty misleading description, given that the ebay page says it's a PAL console (which means it's for the Europe/Australia region). It may rather be that the mistake was listing it as a PAL console in the ebay description, which if that's the case it should immediately be corrected. Screenshot for reference: [URL=http://i.imgur.com/evch3xH.png]x[/URL].