next »

[SuperDisk]

Counter incremented to 10% finished! The engine itself is completely laid out, now it's time for the game code to sit ontop of the framework.

Also, the github megacity-engine project is completely out of date, and shouldn't be used as it's full of bugs.

The chipboard (that contains all of the tiles) is an element. Since I don't want it to be updated each frame (re-rendering each and every tile every frame? Yoinks!) I have created the ChipEngine. This too, is an element subclassed from SubEngine (which is in turn subclassed from Engine.)

This lets me selectively update the chipboard and its tiles, as well as have more tight engine control over the tiles.

Even with all of these layers of stuff, game still runs at about 190 fps. I'm going to try to keep it as high as I can, to have room for more stuff. (the actual game will run at 60)

Sounds complex. Isn't really.  

(Oh and yes, I fixed a bug pertaining to having multiple InputEngines.)

[Pineapple]

Sounds like a really sweet idea! 

[SuperDisk]

I'm thinking of rewriting the game in some other language like Pascal or Java, just because of the ridiculous clumsiness I'm encountering with Python. The simplicity and modifiability of it seems very appealing at first, but it becomes a hindrance about now.

For example, I have 1024 chips, each of them an Element. I have an engine that calls their method update() each frame. Nothing really intensive happens in this method. Yet, just the action of calling the method (no, not the stuff in it!) slows the game down by about 200 fps. (I completely commented out the contents of update() and it still slowed it down) This is absolutely ridiculous if I have to avoid structuring my code properly.

Is there anyone else who is having this problem? It's quite hard to just chuck the entirety of my codebase but still. 

Also, thanks for the support, yonder Madk. 

[Pineapple]

Python is balls, man.

[SuperDisk]

Python is balls, man.

For games at least.

I've decided to rewrite in a different language (Pascal), for the challenge! (let's go with that)

Still using SDL though so it is all thoroughly cross-platform.

[SuperDisk]

After working on and off on the Pascal version, I suddenly remembered something wrong with the Python version that's causing it to lag so horribly:

I ACCIDENTALLY CREATED 4X AS MANY TILES AS I NEEDED.

Hahaaha! kill me

[SolarLune]

I'm thinking of rewriting the game in some other language like Pascal or Java, just because of the ridiculous clumsiness I'm encountering with Python. The simplicity and modifiability of it seems very appealing at first, but it becomes a hindrance about now.

For example, I have 1024 chips, each of them an Element. I have an engine that calls their method update() each frame. Nothing really intensive happens in this method. Yet, just the action of calling the method (no, not the stuff in it!) slows the game down by about 200 fps. (I completely commented out the contents of update() and it still slowed it down) This is absolutely ridiculous if I have to avoid structuring my code properly.

Is there anyone else who is having this problem? It's quite hard to just chuck the entirety of my codebase but still.  

Also, thanks for the support, yonder Madk.  

1. Are you sure that you're going through your code correctly? I mean, will you need to call update on over a thousand objects, or could you just call it on objects onscreen or near the screen? Could you treat blocks of buildings, for example, as single objects?

2. If you're still going with Python, ensure that you're optimizing your Python flow.

3. If you really do need more speed, you could try using a 'speed-up' library like PyPy or Cython.

[SuperDisk]

Added chunks, and the ability to save and load them.

It's using the Python pickle module, which is hard to use because it keeps trying to pickle Pygame surfaces and stuff, so I've implemented the __setstate__ and __getstate__ methods on Chips and Chunks so they may be pickled.

Soon, I'll extend it out so that all Elements may be pickled.

Anyways, it's great to be back on track. FPS is (on average) still above 90, so that's good. I've yet to test it on a lame computer, so that might be a shock.

[SuperDisk]

Today, boosted performance by adding dirtiness to chips and chunks. Now, I can render a full map of grass and water at 111 fps.

 

[SuperDisk]

More optimizations, and chunk saving/loading.

The world is now infinite infinite infinite Infinite infinite infinite infinite

And still running at 120-esque FPS. I'm quite pleased! 
Too bad my summer is completely wasted by huge timesucks though, so I can't be able to goof of on the computer and work on this for lots of time.

[SuperDisk]

Tried to make asynchronous chunk loading, so I made a thing: AsyncGetter.

Use as such.

Code:

getter = AsyncGetter(object.getThing, args=())

<doing other stuff>
if getter.hasGotten():
   result = getter.getResult()

And this is all in a thread, so it's cool and stuff.

[SuperDisk]

And this is all in a thread, so it's cool and stuff.

Python threads are not cool and stuff.

Previously chunkloading used to take a long time and would pause the game for half of a second when the map was scrolled onto unloaded chunks.

Found out the problem (it was another stupid "lol lets load 4x what we need" type of thing). Now scrolling is silky smooth.

All is going according to plan. 

[SuperDisk]

More slow work has happened whenever I feel bored.

Added

• World saving and loading! (this time for real)
• GUI
• Block cursor
• Chat box

The toolbar can be retracted and stuff (and the chatbox moves up and down with it)



Time for working on projects is rather scarce, so updates are far between and pretty non-substantive.

Alas. 

[SuperDisk]

More lame features:

• Minimap!
• Prettied up the toolbar

The minimap shows my world generator, which currently just picks whether to generate a water chunk or a grass chunk, which is crappy. You can click the minimap to change camera position, which I used to generate my name.

I think now I'll get a better world generator, then actually start making gameplay like I've been telling myself to do for the entire duration of this project.