So. It finally hit me how the PC Engine and Genesis used 9-bit color... How does that make sense with 16-bit PPUs? Why just discard those 5 other bits? Sure, having it divisible by 3 makes sense if it's in RGB, but why not 12 or 15 (like the SNES). What possible benefit could there have been?
I never knew what the moons meant when I first started seeing them so I treat the stars and moons the same. It's just another way of saying, "Oh you might want to watch this one. It'll probably be a neat watch."
Personally, I tend to watch movies by clicking on the "popular movies" category and looking for games I like.
Warp, thanks for code snippet, it's actually pretty useful to trying to understand all this. Unfortunately, I'm at my parent's place for the holiday's without access to my development tools so I won't be able to try anything out. But I figure once I get a handle on this "difference between consecutive circles" idea I should be able to develop an algorithm for calculating where the nth pixel goes given some sort of "speed" variable.
I'd like to see this done if only because I don't want to have to play it through myself >_> Such a ridiculous game... The cut scenes are pretty sweet though. Too bad the in game graphics looks about what you'd expect for a port from a family computer somethere between the NES and early SNES in capabilities.
Wow, I just picked this game up; it's really pretty awesome: Kind of like Brain Lord but a little better in some ways and a little worse in others. It has so much going for it: The music and sound design are laugh-out-loud funny for how closely they mirror Kirby's Super Star and the story's delightfully schlocky (It's about demons trying to revive an evil God who's been sealed away and a legendary adventurer's quest to defeat him using the four elemental powers! Oh! There's even a flying high-tech castle full of robots!)
The gameplay's pretty good (damned generic for a dungeon crawling action adventure though) and I especially appreciate the ability to attack in eight directions... The use of magic and secondary characters is also fairly interesting.
This game probably has good potential for a TAS. A TASer could run constantly and I think the route planning would be straightforward enough not to get to boring. There are a lot of enemies too which leads me to hope there's potential for some interesting action, especially because you can be blasting stuff with three characters at once. Also, it's a damn hard game, especially some of the boss fights, but with the right strategy they actually go down surprisingly fast.
Ya, hopefully someone picks this up.
Derakon: I mean cyclical motion of the kind used by the Rotodiscs in Mario 3 (The glowing balls with the grid pattern that orbit around certain blocks).
I figure that if I can get that straightened out there ought to be a fairly straight-forward way to derive more complex patterns like ellipses, hypotrochoids, hypocycloids, etc. Or, then, I suppose that if I had a decent approximation of sinsoidal motion I could derive a circle from that.
Warp:
Ya, I've been thinking there had to be something like that. I mean, quadratic motion can be done with only addition by calling a function that adds one vector X, Y (acceleration) to another (velocity) which is in turn added to a final one (position) every frame. And if a parabola can be made like that, why not any conic section?
I'm dealing with cyclical motion rather than drawings of circles but it seems like the same algorithm should be able to work if the "pixel" is used as the sprite's X, Y position instead (given some tweaking to account for the speed of the orbit). Do you remember if the algorithm had a proper name I could try googling?
I'm in my first year of Game Dev. and I'm just getting into programming for sprites. When I sat down and started thinking about how to move a sprite in circles and ellipses, things got a bit tricky. I found some equations, but it got me to thinking:
How'd they ever manage to do this stuff on the NES? I mean, I'm guessing there's no opcode for sin or cos functions in 6502 assembly... So what did they do?
The whip glitches have come up a lot but to my knowledge nobody's really come up with an instance where they could be used to save a significant amount of time.
Also, as far as I'm aware, the charge-glitch is the fastest way to progress through the game. Although, it seems that there are two charge-glitches. The first works by switching weapons between characters and the second one involves going into the menu and changing settings.
I haven't actually done any TASing so I can't be of much help, but I do have quite a lot of notes for a resource pages... I really should do something with those sometimes soon.
I find it difficult to believe that people are referring to the debug menu as a "cheat code." Did any of you even watch what happened?
The TASer messed around with memory addresses using glitches until they gained access to a debug menu, a development tool inside the code left over from production. That's not a cheat.
We already have runs that allow players to mess around with a game's memory (CT comes to mind...). The only thing difference in this game is that there are better tools to manipulate inside the game's code. It's really not that different than if they'd corrupted memory to warp to the ending themselves instead of relying on debug menu commands buried deep inside the game.
There is a world of difference between manipulating intentional "cheats" inside the GAME and memory addresses inside the CODE. There's a difference between pressing A and B on the title screen 50 times to see the credits roll and using a glitch to access a command in the game's memory that causes the same ending to appear. There is not a difference between the latter and using a glitch to access developer tools buried deep within the code (a debug menu) to access the same command.
It's neat to see, and I think it's cool that the debug menu is simply being glitched to, but on the other hand... Actually, the run I like best is the first obsoleted one that shows off most of the game. Too bad it seems unlikely that a 100% run or very long playaround is going to be done for this game...
100%? I don't think that would offer anything extra unless it were also a playaround, but that might not be such a bad idea. Seriously, the current movie suffers from an over-reliance on Joker Doom.
Given the sheer quantity of glitches in this game though I think there's a lot to show off. Evade being a double of Magic Evade? Blind Doing Nothing? That Rage that allows you to confuse bosses, psycho Cyan... Those aside, I've never even seen the desperation attacks.
The hell? I thought it goes without saying that Japanese Language runs do not obsolete English ones. English is the preferred language; it doesn't count towards actually TASing that Japanese text, etc., is faster. Remember that shit storm we went through when the latest Ocarina of Time run got published, even despite that there were unusual circumstances in that case?
I like this run, but I think it should be posted as a demo without obsoleting the old run.
Seems a lot of the folks on TV tropes don't know what they're talking about under "exception."
It is true that most J-RPG maps lend themselves to just about any topology in that they tend to be a bunch of continents sitting in a single, vast world ocean.
FF2J really could be a poster child for the whole problem though... Maybe it would work if the upper right and lower left corners were poles and the two land bridges attaching to the desert continent were switched so that they properly wrapped around a diagonal equator... Might be undesirable from a gameplay perspective though.
The following wikipedia article has some spiffy diagrams:
http://en.wikipedia.org/wiki/Surface
Ever since I stopped gaming I lost my research position as a grad fellow and now I spend my days lying motionless in bed while high on the psychiatrist prescribed benzodiazepines I routinely abuse. Oh, if only I hadn't sold all my good SNES RPGs on E-bay for a fraction of their value!
3D shapes aren't 2D ones ;) That's just the way things roll when you start using projections.
No how about a game that takes place on a hyperbolic plane?
I've spent a lot of time thinking about this problem. I'm kind of a dork that way...
I don't think it would have been too much trouble for them to use a cube as a projection of a sphere: they could have had 6 maps placed that appear edge to edge and rotated as appropriate (If you rotated the map information and not the graphical tiles, it should look just fine too). Having only one square rotated 180 degrees along one axis and looped along the other has already been suggested, and any of the platonic solids could have been used at least on 3D systems. Using a geodesic dome also comes to mind.
On the other hand, I've also been thinking about how one might have programmed a spherical map in 2-D on the older systems given the convention that north is always "up." Obviously you could never walk past the north or south poles. For the rest, I figure something could have been done using differently sized tile rows and a system to omit or draw certain tiles as necessary to make different rows sync. I imagine you'd try to put the seems in very large oceans, mountain ranges or fields to make this less noticeable. I'm sure it could be done, but it would be a lot of trouble.
I don't know, this kind of sounds like you solidifying my point.
Well, I do think what you're saying is a valid critique, but the fact of the matter is that we don't have a good basis of comparison like we did with the DS Myst run. I've neither played this game nor seen an original hardware run of it. I have no idea whether significantly the same results could reasonably be accomplished by a human being. If they could, there's no doubt that I'd switch my vote to "no." I kind of doubt that's the case though, least of all because of the multiple choice questions that get answered before being asked and the extreme twitch based reflexes some of the games seem to demand.
So am I, which is why I don't like runs like this that are speed-oriented to the point of them being boring. It's just "Hah, I beat it before all of you guys. Now to wait and do nothing for 40 seconds" rather than making something interesting of it.
A significant number of the games are based on score rather than speed though, and in general I think that the optimization of performance is a criteria well suited to this game. I will agree with you that the turbo-button games are trivial though, despite showing the difference between TAS and AI performance. The playaround potential for this game is pretty much handled by watching the AI fail...
Personally, I don't think that mini-game based titles necessarily make for bad game choices. Certainly not more than the story/adventure games. I think these are genres in which entertainment should be a decisive factor.
A longplay of a game like this wouldn't make any sense though: it doesn't really have a story, or secrets, or even intricate non-linear level design to show off. Using the power of emulator tools to max out score though is far more interesting. (And frankly, a welcome change from the usual frame wars. I'm much more in favor of "Tool Assisted Superplays" than "Tool Assisted Speedruns."
Admittedly, there doesn't appear to be a lot of gameplay depth here (the submitter can correct me if I'm wrong) so I would understand if this submission fails. Still, even in that respect I'd like to defend it in comparison to the Myst DS run. First of all, this run looks like good-old-fashioned, real gameplay. Second, there's a great deal of variety, some of which I imagine is open to much more complex and interesting methods of optimization (Perhaps the game where the goal is to collect as much Yen as possible while competing with the enemy AI). Third, this run actually IS entertaining; that a run is entertaining to watch should indeed be considered a contributing factor to whether or not it's a good choice of game.
(Come to think of it though, if there was a significantly similar run on SDA, I'd agree that this should not be published.)
I remember watching this. It was pretty "okay." I'd be happy seeing it published. It seems that everyone who actually knows this game thinks its a good idea to restrict it to runs for Blue and Lute, so if that's what's been the major hold-up it really shouldn't be.
Can this bring up the debug menu? I've only ever heard of it being accessed through the Game Genie code... It doesn't look like dialogue being printed when the glitching starts, and as I remember the debug menu is stored as dialogue: the Game Genie code was supposed to stop dialogue from ending so that you'd keep getting other entries until you reached where the debug menu was stored. I remember the debug menu having a lot of cool stuff (There's probably a FAQ on Starmen.net) but nothing like skipping ahead to Giygas or the ending.
(Personally, I prefer the obsoleted run. It strikes me as having more of a "100%" kind of feel).