Sonic and Sega Retro Message Board: Travelsonic - Viewing Profile - Sonic and Sega Retro Message Board

So I wanted to try my hand at making a simple Mario clone. Being a stickler for accuracy physics-wise, I looked for information, until I saw a guide on the MFGG.
Link to guide (a giant PNG)

Right now, however, I am being somewhat thrown off by the way the data is presented. For example, skidding deceleration ... subtracts 0 blocks, 0 pixels, 1 subpixel, 10 subsub-pixels, and 0 subsubsubpixels from the appropriate values?

Ugh, my head fucking hurts trying to understand this...

So quite a while back I found myself looking through the ELF for Konami's DDRMAX2 PS2 game - Japanese version. Near the end of the file, I found a SHIT TON of this:

Maybe I am not correct, maybe I am, but it looks almost like symbol data - and very important symbol data at that. Funny thing is, whether using PS2DIS, IDA Pro, or anything else to disassemble the file, none of these symbols are actually used, which makes me wonder if it is symbol data that got tossed out during assembly and just stuffed at the end of the file [in which case, that leaves me wondering, what would the data between each recognizable piece of text be?] - this has been bugging the fuck out of me for a LONG time now, and I really want to figure it out... if it is useable data it can be used to make crazy hacks of this game, and if it isn't usable I can stop pounding my head over what this is.

Any and all help in helping me crack the mystery of this is much appreciated.

So I'm teaching myself OpenGL ES since I want to use it in Android game development. Prolem is... I over-analyze things, thus I keep questioning myself about whether I'm thinking about things the right way.

I started my endeavor by doing a simple 3D cube from the book "Hello, Android!" - the base elements of which I am expanding upon for the sake of learning OpenGL stuffs. Now, the lesson required me to create a cube - GLCube was the class name, a renderer - GLRenderer, which implements GLSurfaceView.Renderer, and a new view - GLView which extends GLSurfaceView.

For the lesson I followed I declared a GLCube in the GLRenderer class and handled that, but I thought... if I was going to use OpenGL for games, I gotta handle things differently - time to experiment with different ideas. For the sake of extending that which I've already done, I instead of declaring a GLCube in the GLRenderer class declared a linked list object that takes in GLCubes, put in a function that takes in GLCube objects, and pushes them onto the linked list I created. I then changed my onDrawFrame function so it didn't do anything if the linked list was empty, and if it was not empty, called the draw function for my GLCube class, pops that off the linked list, and rinse/repeat until the linked list is empty, that way it only draws/renders objects that need to be - which will be pushed onto the linked list when updated in such a way where re-drawing them is required.

Obviously if I were to do serious game development, the linked list would take whatever type[s] I want rendered, again I'm only extending what I've learned so far, but I wonder if my thought processes are at the least on the right path/track. I mean, reducing onDrawFrame's behavior to when it has stuff to draw, making it so you add objects for it to draw seems like a logical step - and more efficient than what I started with, but again I over analyze the shit out of things since this is not so much learning OpenGL as an issue with program structure that IMO at least partially comes from how it is explained.

As the topic description says, I feel like a complete blooming idiot right now.

For fun I wanted to see if I could implement the physics as describe in the physics guide in a Megadrive era Sonic engine of my own using C++.

I made Sonic his own class. In the Sonic class, I have friction, max speed, acceleration, and deacceleration set up pre-defined [but not as constants, as underwater ALL OF these values are different if I recall correctly]. For movement, I have a function that takes in an integer representing the key pressed, allowing me to keep the class independent of the graphics/gaming libraries I am using for longer during testing.

[Basically, the "if the player is pressing left," " if the player is pressing right" is now down to a switch statement based on the integer passed as an argument]

The function then checks that code, and for left/right movement, handles it exactly like it was laid out in the guide for when Sonic is running on a flat surface:

the physics guide said:

Only not pseudo code, of course, and with an additional condition where if the X speed is 0 then it adds [if moving right] or subtracts [if moving left] the acceleration, and if nothing is being pressed, the friction is applied appropriately.

Now the problem.

I wanted to test how, when implemented, how a change in X position would look [as opposed to just the X speed]. Like with the X speed being displayed on screen, I then made it so it also showed X position on screen, and I can't help but feel like I am doing something wrong, as the rate of change is absolutely insane.

Ugh.

I was looking at the end of the SLPM file for DDRMAX2 [JP, duh], and noticed something I am curiou about.

Loaded the file into wordpad, made a png w/ a couple of screengrabs, since I'm too lazy to copy+paste ascii in FRHed.



I wonder, are these what I think these are, variable labels?

If so, there seems to be a small fair-ish amount of data between each ascii string - wonder if it is anything that may be useful in incorporating these in my disassembly of DDRMAX2's SLPM file [the disassembly leaving out all these labels]?