Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Gentlefish]

Mostly bumping for your edits' sakes but (just for funsies) maybe try offloading all the characters to a file and read it line-by-line and see how that compares to holding everything in memory?

[Urist McScoopbeard]

Mostly bumping for your edits' sakes but (just for funsies) maybe try offloading all the characters to a file and read it line-by-line and see how that compares to holding everything in memory?

600 strings vs 60k characters might make a difference. I'll give it a try. But... maybe my project is a little too ambitious for python/pygame?

[Gentlefish]

I'd hardly say so; A game you're talking about making is Civ-lite without any graphics. Something like that shouldn't be having too much trouble, considering how unoptimized some games are today that still run smoothly. Python is an interpreted language and does run slower than C/C++/java but that shouldn't be too much of an issue, especially in a project like this.

It's likely something in your loops that might be causing it to run so slowly; I'm at work rn so I won't be able to take a real look at it but I'll see what I can see when I get home tonight.

[exp(tau i)]

Is funk.text_to_screen from this SO answer? If so, the problem likely has to do with needing to re-create a font and surface every time it renders a character. This is where sprites and sprite sheets come in handy -- all the renderer needs to do is load that sprite sheet into memory once and it's super quick to transfer it to the screen.

edit: As a compromise you could also create a map from the character you're interested in displaying to the surface created by `font.render(text, True, color)`. Then, when you want to display a character, look that character up in your map and blit that surface. That should be fast enough for 60+ Hz.

[Urist McScoopbeard]

Is funk.text_to_screen from this SO answer? If so, the problem likely has to do with needing to re-create a font and surface every time it renders a character. This is where sprites and sprite sheets come in handy -- all the renderer needs to do is load that sprite sheet into memory once and it's super quick to transfer it to the screen.

edit: As a compromise you could also create a map from the character you're interested in displaying to the surface created by `font.render(text, True, color)`. Then, when you want to display a character, look that character up in your map and blit that surface. That should be fast enough for 60+ Hz.

Guilty as charged, lol. For this game, simulation, thingy I wanted to keep things text-based for time purposes, so I'll experiment around with that!

[strainer]

Code: [Select]

        ...
        for x in range(self.size):
            for i in currentline:
                terrainarray[y][x] = i
The same x coords are being wrote to the array over and over again.
 
I think you can do this for 100x speedup...

Code: [Select]

       x=0
       for i in currentline:
            terrainarray[y][x++] = i

'size' will be a confusing name for a squares dimension here btw, its a generic term in programming which implies total size - (x*y) for a square. I would call it dimx and dimy here as it seems you may want rectangular maps in future.

[Emma]

Code: [Select]

x=0
for i in currentline:
    terrainarray[y][x++] = i
this wouldn't work in python, python doesn't support ++ to increment a variable.

Code: [Select]

x=0
for i in currentline:
    terrainarray[y][x] = i
    x +=1
would work but I don't think it would be any faster, could be wrong though, it also has the bigger issue of the fact that it's setting every terrainarray[y][X] to the same i, which is the final element of the currentline, I have a feeling that that may have been why it wasn't rendering properly but again I'm probably incorrect
tbh you might not even need the loop shouldn't

Code: [Select]

terrain[y] = list(currentline) work fine?

[strainer]

In other langs you can get the key and value with a for loop, then it would be clear whats happening here:

Code: [Select]

   for key,val in set
      array[row][key]=val

But here your loop feature is just supplying the values of the set (currentLine)
so you need to manage your key (x) yourself. Managing x here with an outer loop is no good because it causes the inner loop to repeat - and the inner loop only has to complete once to have gone through all the values in the line.

It can help to clarify looping sometimes to rename quick single letter variables more precisely.
I avoid using i or j or k for values, to help reduce confusion, and avoid using v,w,x,y,z etc as indexes (keys)

Conventions for variable naming help simplify what many say is the most troublesome issue in programming - naming things.

[strainer]

shouldn't  terrain[y] = list(currentline)  work fine?

Maybe but in many languages you wouldnt do this because currentline returned by the filereader can be a temporary obect, I expect it will be here too. Its also often problematic for efficiency to assign arrays into a multidimensional array like that - it can complicate their memory layout and make them work as 'slow' arrays.

The loop I described should work fine (without that ++).

[bloop_bleep]

There are no temporary objects in Python; Python only garbage-collects objects if no references remain to them. In this case, the function is still holding a reference to currentline, meaning it still exists. Python was designed in such a way that you don't have to worry about pointers or memory leaks or temporary objects for nearly all of the time.

I also fail to see why your code is any faster. Your code does equally many assignments to the array as the original, and furthermore even does the assignments in the same place. It's essentially equivalent.

Python also doesn't have multi-dimensional arrays. Multi-dimensional arrays in Python are just arrays of references to smaller arrays, so terrain[y] = list(currentline) would place a reference to the array list(currentline) at position y in terrain, discarding the previous reference. Note that since we're dealing with references, there's no copying being done at all, so this is probably the fastest solution.

[lethosor]

It's pretty obvious what "multidimensional arrays" means, even when they aren't implemented as a single block of memory.

[bloop_bleep]

It's pretty obvious what "multidimensional arrays" means, even when they aren't implemented as a single block of memory.

Yes, I just wanted to explicitly point out that multidimensional arrays in Python aren't the same as multidimensional arrays in C or other such languages.

[strainer]

I also fail to see why your code is any faster.

Primarily its faster for the fix to the extraneous loop which was rewriting the row 100 times more than required.

Terrain[][] is syntactically speaking a multi dimensional array, its low level implementation can differ from python interpreter version to version.
Always when it is created and filled it must be allocated space and structure in memory.
If you create arrays with list(currentline) and then assign them to terrains elements the interpreter will either copy the created arrays values into the existing structure (so the list() operation was a time consuming extra array creation step), or it will patch a reference to each new list-created array into terrain - thus fragmenting its memory and complicating its structure, leading to performance decrease (in any performance optimized interpreter).

Test it and see

[bloop_bleep]

In Python nearly everything is a reference. By using terrain[y][x] = i, you're telling Python to follow the reference 'terrain' to the array object, then from there follow the reference to 'terrain[y]', and then copy the reference 'i' to index 'x' in 'terrain[y]'. Notice how nothing is copied, except the reference 'i'. (Even then the object that 'i' refers to isn't copied, just the reference to that object.) It isn't like in C++, where indexing an array requires copying that element of the array and bringing that into the function's memory. Your implementation is exactly as fast as the original, since both of them assign to an element of the array the same number of times. However, using Emma's suggestion terrain[y] = list(currentline) is faster, since it's assigning to the array once for each row, instead of once for each cell. If you really want to optimize for speed, that would be what you would go for, even though I don't think it's necessary to do that.

That being said, I will try and benchmark these examples, just to make sure.

[bloop_bleep]

Oh wait, I see. I misread the code; I thought it was filling out every element of the array according to a list of strings. Though in this case it seems to be a problem with the code's functionality instead of a performance problem.