Having trouble setting up bitwise walls for procgen dungeon

I apologize for how absolutely sloppy this program. I'm still very new programming involving more math heavy stuff as well as more intricate logic, so I'm a little out of my depth here.

As you can see running this program, I have a very hackish procedural dungeon generator.

What I'm trying to get to work at this point is for the blocks that make up the dungeon walls use bitwise calculation to change each on to the right frame so it looks like properly connected graphics.

I have it setup the way it is with "on screen" so that it'd keep processing to a minimum... I think. I'm also trying to be more careful about not having a million things running at once since I've had problems with frame rate stuttering since I like to throw a lot at the player in terms of interactive objects.

On that note, I plan on having the walls be destructible and there will be a lot going on with them in terms of interaction (like chain reaction explosions taking out walls, or being able to mine into them and find randomly generated gems, etc.) which is why I was going for having each "tile" as an object rather than using a tilemap, but if you know a solution using a tilemap, that'd be cool too. I guess more than anything, keep in mind my goal is to have the wall blocks interactive.

I hope that all makes sense, and if anyone is willing to help me understand this a little better if you have a solution, that'd be amazing.

Here is the CAPX : mediafire DOT com/?0054ek7p08zjhz4

(sorry for the non link, still a noob here and can't post links)

Thanks in advance!

I'm not totally clear what's happening here - you are creating this dungeon and then you want each path square in it to be decorated differently depending on what's immediately around it ?

My instinctive reaction here is you have a sychronisation problem. Would it be better rather than to try to do everything at once, to split it into two very seperate sections of code - firstly build your paths without any edging effects (e.g. the maze builder bit) and then check the directions for each open path to see which decoration to use. It looks like you are trying to do both at once which strikes me as asking for trouble You could put the two parts in seperate source files which would maintain seperation.

There's a lot of sprites in this as well, but your proc. dungeon is not that densely packed in terms of 'open paths'. It may well be worthwhile using a tiled background for a lot of the default stuff. I appreciate the need for it not to look too cloned, Walls that can blow up etc. could be created dynamically on a seperate layer on top.

I'm not totally clear what's happening here - you are creating this dungeon and then you want each path square in it to be decorated differently depending on what's immediately around it ?

Not the paths, but the walls around the path. If you've ever played Nuclear Throne, it's the same kind of perspective in terms of the way the wall tiles are drawn.

As far as your idea of breaking things down, that's what I was trying to do by only doing the bitwise check / altering of each wall-block when the walls were actually on screen. If I did went the tile route I'd still have to solve my problem of why the bitwise check isn't giving the desired output. Pretty much the idea is that as far as collision detection / altering states of the walls... once everything is initially loaded, it'd loading / unloading things as the player passed by (i.e. via the "on screen" check).

Run the program as it is now and you'll see what I mean. It's really weird. It feels like the bitwise check is kinda working, but offset... but the "on screen" area of the check is fixed to the upper left part of the layout instead of the actual view that's attached to the temporary player I have setup.

Okay. I think I've fixed it, basically see http://studio2.org.uk/c2/working.capx. Somewhat butchered so you might want to use it as a basis

After a lot of experimenting getting nowhere I remembered I had a similar problem in (of all things) Frogger, where I was figuring out continous sprites making up logs and turtles. The problem, I think is when you do xxxx overlapped with xxxx at offset(a,b) it gets mixed up about which xxxx you mean. Inverting this (hence looking for failures and the 15-VA_BITWISE) seems to crack it, along with the foreach action. It doesn't seem to cope well automatically - if you take the foreach out, it doesn't work.

The problem with this is that it does this on every frame which is a bit heavy on the processor, you may want some sort of invalidate flag in SP_001 so it only picks ones it hasn't already done, if you change an edge for some reason you can mark it invalid.

Also, you were using self.x-16,self.y in the offset, when it should have been -16,0 (because it's an offset ), I didn't realise for a while.....

Okay. I think I've fixed it, basically see . Somewhat butchered so you might want to use it as a basis

After a lot of experimenting getting nowhere I remembered I had a similar problem in (of all things) Frogger, where I was figuring out continous sprites making up logs and turtles. The problem, I think is when you do xxxx overlapped with xxxx at offset(a,b) it gets mixed up about which xxxx you mean. Inverting this (hence looking for failures and the 15-VA_BITWISE) seems to crack it, along with the foreach action. It doesn't seem to cope well automatically - if you take the foreach out, it doesn't work.

The problem with this is that it does this on every frame which is a bit heavy on the processor, you may want some sort of invalidate flag in SP_001 so it only picks ones it hasn't already done, if you change an edge for some reason you can mark it invalid.

Also, you were using self.x-16,self.y in the offset, when it should have been -16,0 (because it's an offset ), I didn't realise for a while.....

Thank you so very much!!!

That makes a lot of sense! Will take a look at it right now!

Also, you were using self.x-16,self.y in the offset, when it should have been -16,0 (because it's an offset ), I didn't realise for a while.....

OMG!

That was actually the only problem! Once I fixed that it was working fine!

Thank you so much for helping track down the bug and I'm glad it end up being so simple!

Now I just have to figure out a way to only do checks on the walls that are actually on screen because I'm assuming the reason it's peaking at near 100% processor usage is because the "on screen" check literally has to check even if it's off screen... I mean, that makes sense.

I'm thinking about doing some kind of screen-sized object that activates wall blocks underneath it... hopefully that will work.

If anyone else reads this thread and can think of a elegant solution that'd be cool. I'm always open to other ideas!

Thanks again paulscottrobson !!!! You are a life saver!

I think a potential is to have an isInvalid instance variable which defaults to false. When this is true, it does not need to repaint the wall (e.g. scan and pick the animation), when it is false it indicates it needs to. You can programmatically set it to false if you need to repaint a wall for some reason (e.g. opening a passage).

You could then have something like

SP_001 Is on Screen:

SP_001.isInvalid is set:

Set SP_001.IsInvalid to False

(Scan and reset animations)

Might be better as a sub condition and the other way round - you'd have to experiment to find out.