Slight but noticable slowdown after adding a bunch of active objects for dark effect

[MuddyMole]

How many of those black squares do you have? I notice that the screen scrolls, so I hope you don't have them covering the entire frame, because you only need enough to cover just the visible area (looks to be approx. 11 x 7 = 77 tiles total, which shouldn't be enough to cause any slowdown at all, even without HWA).

eg. http://sdrv.ms/1fZJmuW

[Del_Duio]

How many of those black square objects do you have? I notice that the screen scrolls, so I hope you don't have enough of them to cover the entire frame, because you only need enough to cover just the visible area (looks to be approx. 11 x 7 = 77 tiles total, which should not be enough to cause any slowdown at all).

I have approx. 220 in the new area alone, and much less in 2 separate smaller areas elsewhere on the map. I have the black tiles stuck to their spot on the map though it's not like they're always covering the total visible area. I don't see how I could handle doing it the way that I think you're talking about though, since only certain spots on the map should be in darkness (and you can see other adjacent areas all at once in this one).

[happygreenfrog]

Just as an FYI, chances are, the reason HWA is crashing the editor is because you have it set to use HWA in the editor (it's defaultly set that way, and it actually can cause issues if you are using quick backdrops (that's one thing that could make it have issues, anyway)), so, if you go to the preferences and turn that off, then you should be able to use Direct3D9 just fine (BTW, chances are, the reason everything looks blurry in Direct3D9 is because of the menu bar. If you turn it off, then it should work fine (if it doesn't fix it, then go ahead and use Direct3D8, but that's not going to support as many HWA-exclusive features, and it might not be as fast)).

[MuddyMole]

I have approx. 220 in the new area alone, and much less in 2 separate smaller areas elsewhere on the map. I have the black tiles stuck to their spot on the map though it's not like they're always covering the total visible area. I don't see how I could handle doing it the way that I think you're talking about though, since only certain spots on the map should be in darkness (and you can see other adjacent areas all at once in this one).

If you're sensible, you're already loading all the map tiles from an array - you just need that array to contain an extra value for each tile, to say if it's in light or darkness.

[Del_Duio]

Hey, man. Why don't you try using the textblitter object instead? Just make it pretty big and have it have 32x32 black boxes as characters (you only need 2 characters: empty and black). You can use the callback function to isolate the specific character in an x,y region where your player is, relative to the textblitter's x,y positions, and max that character's semitransparency. I've never done it, but it should be pretty simple, as callbacks are extension-based loops. Using a bunch of actives without HWA in a big frame does probably cause a big slowdown.

That sounds interesting, I'm not positive on how to accomplish this though. The only time I ever use / used the textblitter is for straight text stuff.

I hope a guy called Fifth sees this, as he's bent that extension to fit similar circumstances with awesome results.

Me too!

Alternatively, doing what AyreGuitar suggests is a good idea, but if you go that way don't use overlapping conditions. Compare regions/alterable values instead: always set each black box's alt value A to their own grid coordinates (ie. (x/32*1000)+(y/32)), and then compare that value to the player's (ie. value A of black box = (player's x/32*1000)+(player's y/32) -> make black box invisible. Just remember to add an always condition before this condition that makes the black boxes visible. MMF's object selection loops are much faster than fastloops.

I think the problem's more with the amount of black tiles themselves over the fastloop but this is a good idea. I'm doing something similar in the game with the emergency ladder items that finds out the nearest closest 'tile' relative to the characters' X/Y position since ladders can't be built between spots and be off even by 1 pixel or giant explosions will occur!

That game's looking nice, by the way

Thanks, buddy! I'm trying very hard on this one to make the gameplay as good as I can and not just focusing on the graphics mostly.

[Del_Duio]

If you're sensible, you're already loading all the map tiles from an array - you just need that array to contain an extra value for each tile, to say if it's in light or darkness.

I'm not sensible at all lol!

Actually it's not tile-based like most games like this are. What I'm doing is I made a gigantic png file (1600 x 1600 pixels or so) and drew a bunch of orange and purple squares on it. Then I'm going back by hand and drawing / copying - pasting the walls and etc over those existing squares to make one giant backdrop for the collision (and another giant .png file underneath that layer for the background walls, grass, etc.)

From there, I'm using active objects for the barrels, treasures, enemies, and destructible dirt squares.

I don't know if it's the best way but aside from this slowdown hiccup it works pretty well so far

edit: Here's what I mean, it's a shot of the giant png I have for the map so far. As seen from space or something.

[Del_Duio]

Just as an FYI, chances are, the reason HWA is crashing the editor is because you have it set to use HWA in the editor (it's defaultly set that way, and it actually can cause issues if you are using quick backdrops (that's one thing that could make it have issues, anyway)), so, if you go to the preferences and turn that off, then you should be able to use Direct3D9 just fine (BTW, chances are, the reason everything looks blurry in Direct3D9 is because of the menu bar. If you turn it off, then it should work fine (if it doesn't fix it, then go ahead and use Direct3D8, but that's not going to support as many HWA-exclusive features, and it might not be as fast)).

DUDE!

That's got to be it! I noticed right away that all my visual / layout prefences for the editor were changed around after I installed the new build. Woo hoo I can't wait to turn that sucker back to normal ASAP.

[Del_Duio]

DUDE!

That's got to be it! I noticed right away that all my visual / layout prefences for the editor were changed around after I installed the new build. Woo hoo I can't wait to turn that sucker back to normal ASAP.

Okay this 100% solved the editor crash issue so a VERY BIG THANKS for this help!

Now here's the thing- Direct3D8 solves the speed issue with the black frames but again whenever I go to kill an enemy or destroy a barrel it causes an immediate crash. I've read a bit how the new 3D modes don't support some ink effects (or they're changed around in the editor or something) and whenever the character or an enemy / destructible gets hit it changes the effect to inverted to do a small flashing bit.

Could that be what's causing all the crashes, that ink effect? And if so, is there a way to still accomplish the same thing using what 3D8 (or 3D9) can support now?

[MuddyMole]

Use D3D9 not 8. And yes, anything that can be done with an ink effect can be done using a pixelshader effect.

[Del_Duio]

Use D3D9 not 8. And yes, anything that can be done with an ink effect can be done using a pixelshader effect.

Hi Sketchy!

The only reason I wanted to use 8 over 9 is while using 9 it's making my graphics very blurry. I figured out why though- it's because I'm using the window control object to resize my graphics to a slightly bigger size so the whole thing's not 160 x 100 (or whatever the exact size is, it's something like that). I tried checking and unchecking different display options with 3D9 because I wanted it to work- there was no slowdown and breaking barrels or killing enemies didn't crash the game- but it just looked way too blurry and terrible