Ogmo Editor Build with reduced CPU usage

(Vishal) #1

I have made some changes to the Ogmo Editor source to reduce CPU usage. The editing window control was constantly being redrawn to the screen and I have modified the code to only redraw the window when a user input occurs. I would appreciate it if anyone can test to check if I have not missed anything - if some user input does not redraw the window (enabling/disabling the grid or switching layers always redraws so you can you can use these actions to verify whether the input has been received correctly). If I can get some verification I can submit a pull request to the main repository. The binary is available at - https://bitbucket.org/vishalh/ogmoeditor/downloads/OgmoEditor%20Test%20Build.zip

If someone is interested in the code it is available at - https://bitbucket.org/vishalh/ogmoeditor/src

You can modify the MOUSE_MOVE_UPDATE constant in Ogmo.cs to set how often redraws occur in milliseconds on mouse movement to test the configuration that works best for you. While several other improvements are possible this version runs well enough on my 5+ year old laptop.

(Ultima2876) #2

If I could make a suggestion, is there a way to enable support for extremely large levels? I believe it had a limitation before, iirc!

Also, good work :slight_smile:

(Vishal) #3

I am able to load fairly large levels without a problem, although working with them is kind of annoying without scroll bars and a minimap. Can you tell me what sizes you want to work with that cause a problem? I think I will add scroll bars because they are useful even for smaller maps. I am not sure how very complex large levels would perform, it would help if someone could post some samples that cause performance issues with the binary that I have posted.

(Ultima2876) #4

We were going to make a side-scrolling space shooter with very long levels (4-5 minutes per level) and fast scrolling speeds (8-16 pixels per frame). So maps up to 288,000 pixels across, made up of 32x32 (9000) or 16x16 tiles (18000 tiles). I believe the limtiation was that you could only have 2047x2047 tiles as a maximum in the original version (something to do with it storing the tile indices in a BitmapData, which can only be 2048x2048; a limitation imposed by Flash itself). Matt said he was going to add ‘stitched’ bitmapdata storage but I don’t know if he ever did!

I imagine it probably doesn’t do any view-frustrum culling if large levels cause a performance problem.

(Vishal) #5

For such large levels there is a performance issue. You are right that it does not limit rendering to just the user view, but I am not sure that this problem can be easily fixed - scaling for example is being handled by GDI and it would need a significant portion of the bitmap in the memory in order to perform the zoom operation. Have you tried using Tiled editor? It has a 9999 tile limit but I am not sure how feasible it is performance wise to work on such large maps.

(Abel Toy) #6

Maybe you’re going to see something soon, @Ultima2876… maybe…

And maybe I’m optimizing it to be as fast as possible for large levels, because I needed them. 20000x20000 64x64 tiles (1280000x1280000 pixels) are handled without any problems (and less memory consumption than Skype). You can definitely get waay over that.

And it’s python. And I’m adding additional stuff I need. And maybe you’ll be able to ask for features… yeah, maybe.

Maybe I’ll make an official announcement soon.

(Alex Larioza) #7

Would be cool to see a fix to bounding boxes not rotating with entities.