Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - merrak

Pages: 1 2 3 ... 152
Journals / Re: Merrak's Isometric Adventures -- Alpha Release 1
« on: Yesterday at 12:28:07 pm »
Oh this is looking gorgeous. Is there a new link somewhere that I missed with the latest alpha build for mac? I haven’t gotten to dissect this beauty since you shared your older build on discord awhiles back. Im curious to see what’s changed and improved first hand! Is memory management going to be an issue in the future? I’d hate to run into issues playing this because my old crappy mac can’t handle it :P

Thanks :D Currently there is only the Alpha Build 1 I made (with Flash) back in November. I don't have a working Windows machine, but I could make a Mac version. My Mac Mini's OS is a few generations old, but that can be fixed. Maybe when I get further along I'll build a cheap Windows / Linux dual boot computer so I can make a Windows build.

Memory management is only an issue because up until now, I hadn't put any effort into optimizing it. I put all of my time into improving speed. I always had planned to go back and fix it up, but the Alpha Build 1 alerted me to just how serious the problem really is.

Separating the map building process from the game loading process will make a lot of things easier. RAM, as I saw, will improve by a lot more than I thought. But this will also open the door to making non tile-based maps. Tiles are convenient and makes it quick to build levels, but as far as the renderer is concerned, it only sees planes. I could easily make more intricate maps. The only things I'd need to rework are some of the physics routines (I use tile coordinates to optimize physics code) and I'd need a new map editor.

Journals / Re: Merrak's Isometric Adventures -- Alpha Release 1
« on: January 19, 2019, 11:21:26 pm »
Shoot! I recently got projectile weapons working. It took a lot longer than anticipated, but most of that time was fixing a bunch of little bugs that this project uncovered. Here's the result.

The last major hurdle behind putting out another demo is memory. I've been putting it off long enough, so now it's time to dig into it. I wrote a small routine that dumps the memory contents of each sector as it's generated. All this time I was assuming most of it was graphics, but that isn't the case much at all.

This is the typical output, showing RAM usage (in MB) for each sector

Code: [Select]
Design_202_202_LoadGameBehavior.hx:795: Building map 6 of 10
MapNode.hx:1815: MAP: level2b
MapNode.hx:1817: Sort Buckets ............... 0
MapNode.hx:1818: Sort Nodes ................. 0
MapNode.hx:1819: wpOptimize ................. 0
MapNode.hx:1820: Make Auto Lights ........... 0
MapNode.hx:1821: Make Doorways .............. 0
MapNode.hx:1823: Connect Wall Planes ........ 142
MapNode.hx:1824: Make Walls ................. 0
MapNode.hx:1825: Make Statues ............... 0
MapNode.hx:1826: Connect Buckets ............ 0
MapNode.hx:1827: Construct Wall Faces ....... 19
MapNode.hx:1829: Make Visible Walls ......... 0
MapNode.hx:1830: Make Subsectors ............ 0
MapNode.hx:1831: Make Canvas ................ 0
MapNode.hx:1832: Sort By Dependency Graph ... 119
MapNode.hx:1833: Set Layers ................. 0
MapNode.hx:1835: Make Visible Wall Faces .... 0
MapNode.hx:1836: Compute Ambient ............ 0

The graphics are generated in the routine "Construct Wall Faces", which takes a marginal 19 MB compared to "Connect Wall Planes" and "Sort By Dependency Graph"

This is actually good news in a way. Most of the RAM hogs are living in the code that builds and sorts the walls. It shouldn't be too difficult to have the map editor build the walls and then save the relevant data in a file so that, when the game loads, it doesn't need to do all the calculations. It will also greatly speed up the game loading process, since computing the wall coordinates and order is what it's spending most of its time doing when it loads.

Right now total RAM usage is ~1150MB doing everything in about the worst possible way for storing data. It looks like dumping all the graphs can get me down to ~300MB, which is still high, but can be trimmed down further if I don't want to load all the level graphics at once.

Windows / Mac / Flash / HTML5 / Re: Soultrail Saviour [WIP]
« on: January 17, 2019, 10:19:16 pm »
Looks great so far. Did you end up getting the RAM issue fixed? I usually just modify the original launcher rather than downloading a new one. Change the line -Xmx###m \ to whatever amount you want. Mine is set to -Xmx24072m \ which will reserve 24GB memory. Just don't reserve more RAM than your machine actually has, and leave some for your other programs.

@squeeb I think the vines are part of the structure holding up the platforms. At least, that's how it looks to me.

Ask a Question / Re: Can't hear any sound
« on: January 16, 2019, 08:14:17 pm »
Did you change any of the sounds? Checked that your sounds are configured correctly with regards to metadata, etc.?

Ask a Question / Re: a question about how many tiles can i use?
« on: January 16, 2019, 08:04:44 pm »
I've never tested to see just how large of a scene you can create. Do the logs give any hints? One thing that happens with regards to tiles is collision shape optimization. I could see that routine scaling quickly with the tile dimensions--but that runs on the toolset, not the engine, so I don't have much insight into it. Justin might be able to comment on that. There could be other bottlenecks as well. Earlier in 3.5's development I think they overhauled the tile optimization algorithm--so if that is the hang-up then the new Stencyl should solve the problem. But that's just my best guess of what the problem is.

It should be going public soon, so you would have the opportunity to try.

This might be a red flag that this is not the best approach to take to creating a large open world. For instance, do you plan to implement pathfinding?

At some point you need to consider how to break the larger world into smaller chunks. When the numbers get large enough, the toolset, engine version, etc., is irrelevant--the math is just not on your side.

Ask a Question / Re: Identifying connected puzzle nodes?
« on: January 12, 2019, 03:34:19 pm »
You can use A* if the nodes can have multiple connections.

Do you have all of the Windows development required executables? Not a Windows expert here, but you're missing several .exe files, such as:

ERROR: The process "cc1plus.exe" not found

Journals / Re: Merrak's Isometric Adventures -- Alpha Release 1
« on: January 11, 2019, 01:12:49 pm »
New Year Update! I thought I'd leave a quick update on how things are progressing, just to ring in the new year. I've been busy at work lately, so most of these are December updates. Once I settle into my new semester I will have more free time and maybe get another demo up. I'm still aiming for a January demo. I have a lot of new features to show off  :o

Highlights: I got all of the "A" maps done--at least, a rough draft of them. I expect I'll need to revise some of them, but the start is there. For a reminder, the game is divided into four main areas ("towers") with three levels each (A, B, C), all connected by a central hub. So this means I have about a third of the maps done. But I actually have a bit more than that, because I already started a couple of the "B" maps before I decided on a final structure. Each tower also has a D level, but that map functions as a "boss level" and is small.

While I generally dislike mazes, I decided to lock all of the doorways out of the central hub area and make the player find the key. The thinking is that the player will find some of the power-up items before finding the key. I placed the key pretty deep into the map, and also spread out the power-up items so that the player will feel some progression in their power as they move away from the starting room.

I've also been going through the comments I received on the first demo. The big issue: Flash-dependent bugs, will probably be the last one I tackle. I'm hoping fixing some of the memory issues might also fix the Flash issues, or at least give me some more evidence to go on. I did stumble upon, and fix, some significant bugs regarding objects handling.

I got to the point where I couldn't even play test because there were too many objects to carry around. So I went ahead and revised the inventory UI screen. Here's what I have so far.

It's not perfect, but it is a lot more usable. You can select category by moving up/down, then select cards in a category using left/right.

The current card is always on top, and the correct name now shows on the prompt. I want to redo the cards graphics a bit so that the highlighted card is brighter, but that aside I think this is a significant improvement.

It also gives me a menu, so I can now add the usual save/load, volume, controls configuration, etc. that players expect to see.

Improvements already on my to-do list include: showing some quick stats about the player character (HP, experience points, etc.) in a more accessible location, highlighting the currently equipped items in some way, and maybe adding some decoration or something just to make the screen look nicer.

Ask a Question / Re: Android App Crashes On Interaction
« on: January 10, 2019, 09:49:30 pm »
How much of the log would you need? I looked through it a bit for anything obvious and it's just massive...

Just do the "generate logs" and attach the .zip file. I don't do much Android development so I'm not the best person to review it... but I'll take a quick look and see if I do spot anything.

Ask a Question / Re: Android App Crashes On Interaction
« on: January 10, 2019, 08:45:20 pm »
SIGSEGV is a segmentation fault, but without the log there's little else to say. Does the game work if you compile it as a desktop game? If it doesn't then you should be looking for an uninitialized list, actor attribute without a value, or any of the other kinds of errors that would show up as "error 1009" in Flash or a crash on a desktop build.

You're right, I just misread the screenshot. You can probably find some clever ways to segment the scene and reduce the number of actors to sort, but that, on top of optimizing the sort, seems like an unnecessary complication when you're code's speed is almost up to par.

Either make the sorting part of the routine more efficient, or find a way to segment the scene into smaller pieces and apply the original sorting routine on just that segment. Just one of those two optimizations should be good enough. You probably won't need to do both unless you hit another lag wall.

Ask a Question / Re: Another game won't compile into flash
« on: January 05, 2019, 04:29:44 pm »
This is the only thing that stood out to me

"Method extraParams not found on class lime.Lib"

Might be a question for Justin? If no games publish correctly then a problem with lime makes sense. What changed between when the last game you compiled worked and when it stopped working?

Could you perhaps explain it a little more? I can't seem to grasp what you're telling me.

Here are some basics. Stencyl is built on top of OpenFL, so it's helpful to understand a little about how OpenFL handles these kinds of things.

OpenFL implements Sprites, which you can take as anything visible or tangible in the scene. These include images, Actors, and even Layers. So you can think of Layers as large, invisible Sprites

Every Sprite can have child Sprites. If you're not familiar with this analogy, think of paper cut-out animation (like in South Park) where different visuals are glued together. In this example, the body is the parent Sprite, and the eyes, mouth, clothes, etc. the child Sprites. This hierarchy can be multiple levels deep. For instance, the eyes are child Sprites of the body, and each eye has a child Sprite of its own--the pupil.

There are a lot of advantages to this architecture. If you move the parent Sprite, the children move along with it. If you hide the parent Sprite, the children all hide as well.

So what you need to visualize is that every Sprite has a list of children, and z-index refers to the child's position in this list. Since a Layer is just a Sprite, then each actor's z-index is its position in the Layer's list of children.

Here are two approaches to implementing z-index based depth. You can continuously sort the list of children. This is the approach your behavior you're using takes. It's the simpler solution, but comes at the cost of not scaling very well when the number of actors gets large. The other approach is to insert actors into this list as they're created, and change their position as they move. This approach is more complicated to program, but will result in faster z-ordering.

The problem you're running into with the trees is that there are a lot of actors to continuously sort. So you either need to implement a more efficient sorting routine, or reduce the number of trees.

Keep in mind you don't actually have to delete trees to reduce their number. All you really need to do is find a way to not sort every tree. I thought of another solution that might work. I noticed your behavior loops through every layer. What if you broke your map up into small, screen-sized sections, and assigned a layer to each section. Modify the behavior so that instead of sorting  every actor on every layer, it only sorts every actor on the visible layer.

1st paragraph:
There isn't an 'on created' event, where should I be setting and resetting this attribute? (The delay is happening in a 'every .075 secs' event)

2nd paragraph:
So how exactly would I do this? I didn't write the behavior, so I don't know how I could modify it without messing it up.

1-- You'll need to create it. I attached an example from one of my behaviors--how I usually set this kind of delay up (ignore the other blocks, just look at the last wrapper).

2-- This is where things get tricky. You're probably better off writing a new behavior from scratch and using the current one as an example of how to use blocks to manipulate z-order. This same topic actually came up in the Discord Chat not too long ago. Torcado mentioned he had a write-up of how he did z-order in Bunosphere, and the source is also available for illustration. I don't know where the write-up is. I'd expect his solution would be better than mine for your game, since the solution I wrote up is designed for a game with a 3D world and an isometric perspective, and so I'm thinking about things different than for a 2D game world and oblique projection.

Also see:  But the haxecoder link they post is dead. I think this is the original text, though:

There's a lot of opportunities to make this faster for your particular needs.

I don't know why there's a 0.02 second delay in the updating event. I suspect this was a fix to prevent the re-ordering from occurring before all the actors loaded. In that case, this isn't an efficient way to impose a delay, since you're constantly creating and deleting listeners. Try replacing the do after loop with an 'if (attribute) is true' wrapper. Set the attribute to false initially. Then, in the 'on created' event, say 'do after 0.02 seconds, set (attribute) to true'. This will take the do after wrappers out of the always event and still impose the 0.02 second delay

Next, you shouldn't need to be constantly reordering every actor. You only need to order the trees when they're initially placed, then insert moving actors into the z-order list when their y-value changes. This is your biggest bottleneck here. An actor's z-value only needs to be set if it moves vertically, or is created and placed into the scene. Even then, you only need to set that particular actor's z-value. You don't need to change all of the other actors'.

Pages: 1 2 3 ... 152