Kain

Well, probably not completely random (meaning forums linked to us are probably somewhat in danger), but it definately seems like a "casual" hacking.

There are thousands of hackers who go arround attack random sites. That doesn't mean he won't be back to screw this place up more. If the door isn't closed when he comes back, he probably will.

It sounds like one or a number of your control objects are wasting too time. I don't think it's the actual method of activation that's causing the slow-down.

http://www.thefreecountry.com/compilers/cpp.shtml Oh, there are lots all right.

It depends on how much you have and how far they go. The easiest thing is to keep them active, but you could deactivate them if you had a good system for doing it. Also, you could consider increasing the size of the active area for things like that since enemies should probably deactivated since they take up a bit of time.

Oh, well I've never used MMF's editor with more than a small degree of understanding.

There are many ways to cut down on speed. One way you almost always need to do when your room has very many objects that don't always need to be doing something is deactivating instances. Deactivate instances outside of the view that aren't important: //Activate all objects instance_activate_all(); //Deactivates everything some ways outside the view instance_deactivate_region(view_xview[0]-100, view_yview[0]-100, view_xview[0]+view_wview[0]+100, view_yview[0]+view_hview[0]+100,0,1); Also, there are some objects you don't want deactivated no matter where they are (control objects, bosses, etc.). For these, you should make all of their parents an object "objControl" and perform this code after the one above: instance_activate_object(objControl); Or just have one of those for every type of object you want to be always active.

Besides, you can't just turn D3D on or of. GM6 is constructed completely on the back of D3D the way GM5 and some earlier versions were made from DirectDraw. That's why you can the D3D functions even when D3D supposedly isn't turned on. There are some tricks for adding objects to the editor. For example, holding shift will create objects as you hold click and drag it along. Also, holding ctrl will let you grab and drag an object and holding ctrl and right-clicking will let you edit its properties (including giving that instance specific code). And of course you can turn off "delete underlying" which makes objects be able to overlap without deleting them. Anyway, the tile system is rather limited, even more so than with previous versions. Hopefully it's something mark's fixing. But you could always make your own tile system. Edit: But it needs some work and has been virtually unchanged since version 4. Some things the map editor can benefit from to get an idea of what it's lacking: multiple undos and redos (even MSPaint has 3), an editable object menu so you don't have to go through a path every time you need to change an object, intigration of object and tile placement.

Which is what would make it so interesting.

A whole forum full of active members who happen to be the same person (or rather 5 members per person or something). That'd be interesting to see.

Checkpoint's collision with Sonic: global.check_point = true; global.check_pointx = x; global.check_pointy = y; Unless you mean storing them somewhere else, like a file or something.

It's not quite the same without a good controller, but I did re-go through the interesting adventure mode a little.

I have Ehrgeiz, but it's broke. The broke-in-half kind of broke but with more pieces.

There is a code equivilant for "repeat" in the "Other" section of the "Control" tab(the one with the winding arrow). But you need to use the block statements for more than one event and once you start using those, IMO, it gets about 10 times more complicated to read in DnD than in GML.

I'm not too sure exactly how fast loops work, but GM's got real loops built-in. It has them of the for, while, do...until (pretty much do...while), and even repeat variety. Read up on them in the GM manual GML Language Overview section.

There's no need to be throwing dice (or using the function "random( # )") any more times than needed, plus you usually want to somewhat control timed events. I mean, it's not likely that you're system will take a minute to release a bubble, but it could. Anyway, instead of throwing a dice every step, just throw a dice every time you make a buble and that dice will determine the amount of time before the next bubble (using alarms). For example, if you wanted a bubble to come between 2 and 10 seconds, you'd use this code: alarm[0] = 2*room_speed + random(8*room_speed); You'd put that in the create and the alarm[0] event. Also, in the alarm[0] event, you'd create the bubble. Everything else is as LarkSS described.

Those complex streaks of gas where the blue and red seperate that give the nebula its eye-like depth look very amazing in the high-deg image on NASA's site. Anyway, since it doesn't say otherwise (and it usually, if not always, does), one can assume that those are its true colors and not colors formed from a combination of shifted x-rays or other ranges and vissual like many of the pretty astronomy pictures you see. But looking at the NASA picture-a-day website, you get quite a bit of stunning space pictures.

Ah, what ever happened to Megaman Legends? Or the normal Megaman series for that matter... But the game's melee and anything=weapon systems do look extremely awesome. The pretty much entire game taking place in a mall aspect looks a little less awesome, at least to me. The time-limit and forced missions things keeps it from feeling GTA-style freeform; to me it feels like it's trying to be an updated Streets of Rage style fighter and I guess that's pretty cool. I'll have to wait and see, but I don't think I'll be getting an 360 anytime soon.

It's fairly standard in any post-Genesis Sonic games and it's not a trivial thing to implement (it's integrated with the movement engine usually, which people rarely make their own). It's not surprising that you get a bunch of questions about it. Anyway, sonic122, what program are you using and what engine for that program are you using?

I can't trust myself to work, so I can't expect someone else to trust me. Simple as that for me.

Actually, it's a tiny bit more complicated than this. And judging from you're code, Dami's slightly changed his layering engine since the old versions, so it'll be even more complicated. If you understand the way his layering works, however, you can easily create any sort of layer (including a grinding layer) to create 360 degree movement without needing to understand anything about how 360 degree engines work. To create an independent grinding layer using the build in functions, the idea is to (whenever you're on the grinding layer) check for objGrind objects and only objGrind objects. The problem with the code you've posted is twofold: the fist problem is that the code checks for collision with objSolid, no matter what the layer argument is set to; the second problem is that the previous code is designed for two different types of layers (high=1 and low=0) and you need one that suports three (high=1, low=0, and grind=2 or something). The first step is to individually change every collision code to where it checks only for objGrind if layer=2 and if layer!=2, check for objSolid then if layer=0, check for objLow/if layer=1, check for objHigh. Logically, that'd look like this: if(argument2==2) return place_meeting(....,objGrind); else { return place_meeting(....,objSolid); if(argument2==0) return place_meeting(....,objLow); else return place_meeting(....,objHigh); } //Note that the .... should be the same for each and is the //same as it was before you changed the code That's using (from what I can tell), the method you have. Though, I'm not 100% familiar with the particular engine make you're using, so a link would help. Once you've fixed all the collision functions to incorperate the grinding layer, the coding's pretty simple: if ( player_collision_bottom( x, y, objGrind)) { //Start Grinding action = grinding; //set speed layer = 2; } else if( action == grinding ) { //Stop Grinding layer = 0; action = falling_out_of_grind; } And that code can go just about anywhere in a step event. (Note, though, that I'm assuming much in this engine, so I'd love to see the version you're using).

{some spoilers are probably in this post} That was Ikari's (the older detective) old-fassioned land of make believe where Tsukiko Sagi was hiding from Little Slugger and the world's scorn. I think the main point was to show that the younger detective (Maniwa), because of this incident, had become the same type of crazy that the old man he kept running into was. You know, that whole mirror, doubling thing. To be fair, it had showed that he was already pretty unballanced in how he so willingly played into whatever farfetched proposition came before him and the way he was preaching about Little Slugger on a suicide discussion chat room. Anyway, the story's not that deep and meaningful and I don't know that it was meant to be. The only person who might have had something thoughtful to say in the story was Ikari's wife. The story had more emphasis on a believable, but a little extreme, human, display of emotions and repressions and such than having a deeper meaning and great twists. I'm pretty sure you were supposed to figure out the origin of Little Slugger- they had spelt it out for you. I'm not saying it was an amazing ending, because it wasn't, but the momentum and presentation that the show had developed was very much realized in the ending.

Meh, I don't really like The Fairly Odd Parents (never really disliked it either). The only new Cartoons I like are SpongeBob (which is way past its prime) and The Grim Adventures of Billy and Mandy. But Invader Zim I loved, and now that I hear what they did to Angry Beavers, I hate Nickelodeon. I can understand about Invader Zim, but it still sucks majorly to them.

It goes without saying that higher resolutions need proportionally higher accelerations, but as long as the character size to screen size ratio stays the same, it's not going to be/look faster. And I think the classic games have a perfect character size to screen size ratio. Personally, I think 320x240 is the perfect resolution even for original graphics, but I see why others want higher.

Game Maker engines use the same accelerations. Dami's GM engine (maybe his TGF/MMF too) uses values calculated by Taxman as the accelerations used in the Genesis games. I used to use extremely fast accelerations (I'm sure noone remembers Sonic Terminal Velocity), and when if comes to level designs, it usually doesn't work as well.