Some questions in TGF (if any1 uses it here)

[Eidolon]

1. How do you put parralex in TGF using static? Every time I try, sonic just falls through the ground.

2. Using the Direction Calculator, can you make 360 grinding. If so, what about a 360 moving engine? If yes, how?

thanks in advance

 

[Shadow Hog]

1) Not entirely sure, since, while I largely get around the falling through by hiding some background objects behind the large active object that is the foreground, the background active can never seem to scroll just right (id est: if I run to one side of the screen and back, the screen is displaced from its starting point, which results in a very funky looking thing indeed). For now I just turn "follow the playfield" off, causing it to move with the screen pretty much perfectly.

2) Go look over the Sonic Fan Game HQ forums, particularly the Help sections, and particularly for engines made by a guy called Damizean.

As for what I'm using right now... sort of a mix between TGF and MMF demo. MMF definitely has more power, but TGF's image editor is a LOT more convenient...

 

[Monsteriestyn]

aw man i was gonna suggest sfghq!!

 

[JTE]

You REALLY should use MMF for any bit of advanced stuff, because TGF makes completely random bugs throughout your game that you cannot fix. It's a major pain in my @$$ when I make 2 balls with the exact same events and everything and one rolls better then the other because of some half-deleted event I made while programming it in the first place... Stupid TGF... All MMF does is crash, and it's completely predictable.

 

[a441]

You should program in C or C++ using SDL for any advanced stuff.

 

[JTE]

I dun think he's advanced enough to learn any REAL languages just yet, a441. But hey, it's a goal to shoot for...

 

[Shadow Hog]

I've long wondered how exactly I'm supposed to program a game in C++ with collision detection working properly. My latest attempt (using OpenGL, in this case) used an array to do the work for a pseudo-3D, Wolfenstein 3D-style situation... thing is, it doesn't work very well. At all. But then, OpenGL's coordinate system feels very awkward (positive in the Y axis is... up?), so that attempt was pretty confusing to begin with.

I may have to look at this SDL thing...

 

[a441]

Well, SDL, although it can be used with OpenGL, is basically 2D.

In SRB2, collisions are handled as though each object were a cube. To speed it up, the map is split into a set of 128x128 blocks (based on X/Y only, not Z, which in SRB2 is vertical height), and the game tracks which block each object is in. That way it doesn't have to check if an object is colliding with another object halfway across the map.

 

[Shadow Hog]

And here I thought it might have to do with those little arrow things.

Actually... what DO those do? I'm not sure I understand the syntax. Heck, I'm sure I DON'T understand the syntax.

 

[a441]

What little arrow things?

 

[Shadow Hog]

    // special keys state
    if (ev->data1 == KEY_SHIFT && ev->type == ev_keyup)
    {
        shiftdown = false;
        return false;
    }

Or, more specifically,

if (ev->data1 == KEY_SHIFT && ev->type == ev_keyup)

Those arrow things.

 

[a441]

ev is a pointer to a struct. That is, it contains the memory location of an object composed of smaller objects (elements). ev->data1 accesses the "data1" element of the structure that ev contains the memory location of.

This is a feature of the C language. It could be used in some way for collision detection, but it could also be used for just about any programming task imaginable. C is just a programming language, not a game creation toolkit.

 

[Shadow Hog]

Of course. C and/or C++ are capable of virtually ANYTHING you want them to so long as you have the know-how to do it. Thing is, I'm still relatively new at this (although I'm leaving the rest of my class in the dust), so there are still some concepts I don't grasp.

Memory locations being one of them, though with any luck we'll have that covered by the year's end.

I hope. The amount of things the rest of the class CAN'T do scares me. Seriously, HOW hard is it to nest if statements? To declare call functions? To have the right variables for the right needs? To do simple math (these guys have trouble with the distance formula, for crying out loud; all it took me was a slight rewrite using sqrt() and pow() and it was working just fine...)

 

[a441]

You don't need pow() to square something. Just multiplying it by itself is faster.

For a fast way to approximate 2D distance, look at the P_AproxDistance function in p_maputl.c.

 

[JTE]

Yay, I learned how to do those arrow things myself beforehand! I made my own spmoves struct, but it doesn't work right. >.< I have it Z_Malloc'ed and stuff and the stupid thing just crashes... Btw, a441, aren't they circles? Not squares? I mean, the top and bottom are flat, but other then that I can "feel" the roundness of them.

 

[a441]

Maybe it seems that way because of how the sprites don't rotate completely.

 

[JTE]

Strange... Because I've never felt any "corners" on anything... Even the item boxes (Yes, I like to run headlong into item boxes...) are round enough that I can hit them from any angle... And there's a lot of circumference stuff in the collusion code that I don't understand... And how would it use the definition of PI and the mobj's radius otherwise? I dunno how to calculate the area of a square, though that's exactly what I did in Zippy World...
Oh, for anyone who doesn't know what Zippy World is, it's this extremely laggy script I made for mIRC that's too advanced for open-source programming to handle. It just doesn't have any Zip to it. I did have ceilings you could run under and they'd turn invisible so you could see around the room and stuff, though. Oh, and mobjs. Lots and lots of mobjs. Scenery, mostly. And it had the ability for maps to be either internal OR external, the latter being twice as lag-ridden.
Oh, I've gone off now, sorry. What was I saying?

 

[a441]

You need to learn C and SDL and make a truly zippy world.

PI is used for rotating stuff, like the spikeballs that rotate around Boss 3.

 

[JTE]

Oh, oh, oh, if mobjs are square, how can you fit in that 64 x 64 hole in GFZ1 sideways?... Oh wait... the players are 16 x 2 = 32... !@# Well, I'm gonna make a 32 or 33 hole and see if you can fit in it sideways! brb-ish.

 

[Shadow Hog]

Oh, oh, oh, if mobjs are square, how can you fit in that 64 x 64 hole in GFZ1 sideways?... Oh wait... the players are 16 x 2 = 32... !@# Well, I'm gonna make a 32 or 33 hole and see if you can fit in it sideways! brb-ish.

Judging from how running into a Spider Mastermind will always result in you running around it as if it were a giant cube, I'm fairly certain you'll find that collision in DOOM just ain't flat.