• We've upgraded our forums. Please post any issues/requests in this thread.

Optimizing Python game

Joined
Feb 18, 2010
Messages
1,715 (0.60/day)
Likes
408
System Name Eldritch
Processor AMD Ryzen 5 1500X
Motherboard MSI B350 PC Mate
Cooling Satan's butthole after going to Taco Bell
Memory 16 GB G.Skill Flare X
Video Card(s) nVidia (Gigabyte) GT 740 2GB
Storage 80 GB IBM, 2 TB WD Green
Display(s) Dell 2007WFP
Software Debian Buster
#1
I'm currently pretending to make a game, it uses a hex-based tile system and uses Python 3.2 and PyGame. Most everything is fine, but I decided I want to use really big maps - and therein lies the problem.

I am currently using a map that is ~22000 tiles big, and guess what? Things are really slow, and I've spent about 3 hours optimizing every thing that's related to it.

So here is my unoptimized code:
Code:
def drawhex(tile, layer=0, pos=(int(VIEW[x]+(MODE[x]/2)), int(VIEW[y]+(MODE[y]/2))), mul=STEP*VIEW[z]):
    #This needs to be seriously sped up:
    tile.polys = ((tile.verts[0][x]*mul+pos[x], tile.verts[0][y]*VIEW[z]+pos[y]),
                  (tile.verts[1][x]*mul+pos[x], tile.verts[1][y]*VIEW[z]+pos[y]),
                  (tile.verts[2][x]*mul+pos[x], tile.verts[2][y]*VIEW[z]+pos[y]),
                  (tile.verts[3][x]*mul+pos[x], tile.verts[3][y]*VIEW[z]+pos[y]),
                  (tile.verts[4][x]*mul+pos[x], tile.verts[4][y]*VIEW[z]+pos[y]),
                  (tile.verts[5][x]*mul+pos[x], tile.verts[5][y]*VIEW[z]+pos[y]))
    #This is fine:
    pygame.draw.polygon(LAYERSURFACES[layer], COLORS[tile.terrain], tile.polys)
    if GRIDSPACING: pygame.draw.lines(OVERLAYSURFACES[0], (0, 0, 0, 255), True, tile.polys, GRIDSPACING)
Which takes ~1.5 seconds (also, it gets called for every tile).

And here is my optimized code:
Code:
def drawhex(tileset, layer=0):
    #Sorry, I had to optimize the shit out of this
    #This needs to be seriously sped up (still a significant slowdown while zoomed out):
    #for tile in tileset.values():
    #timmay = time.time()
    pos = (int(VIEW[x]+(MODE[x]/2)), int(VIEW[y]+(MODE[y]/2)))
    mul = STEP*VIEW[z]
    posx = pos[x]
    posy = pos[y]
    zoom = VIEW[z]
    #These seem help when zoomed out
    drawlayer = LAYERSURFACES[layer]
    overlay = OVERLAYSURFACES[0]
    space = GRIDSPACING
    color = COLORS
    #Seems to help a little bit:
    xA = 0.00
    xB = 0.00
    xC = 0.00
    yA = 0.00
    yB = 0.00
    yC = 0.00
    yD = 0.00
    for tile in tileset:
        verts = tile.verts
        xB = verts[1][0]*mul+posx
        if xB > 0:#Maybe check Y values first?
            xC = verts[4][0]*mul+posx
            if xC < MODE[0]:#Width
                yA = verts[0][1]*zoom+posy
                if yA > 0:
                    yD = verts[3][1]*zoom+posy
                    if yD < MODE[1]:#Height
                        polys = tile.polys
                        xA = verts[0][0]*mul+posx
                        yB = verts[1][1]*zoom+posy
                        yC = verts[2][1]*zoom+posy
                        polys = ((xA, yA),
                                 (xB, yB),
                                 (xB, yC),
                                 (xA, yD),
                                 (xC, yC),
                                 (xC, yB))
                        pygame.draw.polygon(drawlayer, color[tile.terrain], polys)
                        if GRIDSPACING: pygame.draw.lines(overlay, (0, 0, 0, 255), True, polys, space)
                        #print(time.time()-timmay)
Which takes ~.08 seconds at default zoom and ~.72 seconds zoomed out as far as I can go. It only gets called the one time and does everything from there and tileset is currently a frozenset (I was thinking about sorting it into a tuple and culling from there).

Unfortunately I'm still not happy with that and the only way I can think to make it faster is to rewrite it in C - which I really do not want to do (at least not at the moment).

So do you have any tips (aside from the sorting, which I'll get on later today)? Anything small little thing should help (seriously, it loops 21,931 times, anything will do).
 

FordGT90Concept

"I go fast!1!11!1!"
Joined
Oct 13, 2008
Messages
20,927 (6.24/day)
Likes
10,026
Location
IA, USA
System Name BY-2015
Processor Intel Core i7-6700K (4 x 4.00 GHz) w/ HT and Turbo on
Motherboard MSI Z170A GAMING M7
Cooling Scythe Kotetsu
Memory 2 x Kingston HyperX DDR4-2133 8 GiB
Video Card(s) PowerColor PCS+ 390 8 GiB DVI + HDMI
Storage Crucial MX300 275 GB, Seagate 6 TB 7200 RPM
Display(s) Samsung SyncMaster T240 24" LCD (1920x1200 HDMI) + Samsung SyncMaster 906BW 19" LCD (1440x900 DVI)
Case Coolermaster HAF 932 w/ USB 3.0 5.25" bay
Audio Device(s) Realtek Onboard, Micca OriGen+
Power Supply Enermax Platimax 850w
Mouse SteelSeries Sensei RAW
Keyboard Tesoro Excalibur
Software Windows 10 Pro 64-bit
Benchmark Scores Faster than the tortoise; slower than the hare.
#2
Minimize your updates to only include data that requires updating.
 
Joined
Aug 10, 2007
Messages
4,059 (1.07/day)
Likes
1,123
Location
Geneva, FL, USA
Processor Intel i5-6600
Motherboard ASRock H170M-ITX
Cooling Cooler Master Geminii S524
Memory G.Skill DDR4-2133 16GB (8GB x 2)
Video Card(s) Gigabyte R9-380X 4GB
Storage Samsung 950 EVO 250GB (mSATA)
Display(s) LG 29UM69G-B 2560x1080 IPS
Case Lian Li PC-Q25
Audio Device(s) Realtek ALC892
Power Supply Seasonic SS-460FL2
Mouse Logitech G700s
Keyboard Logitech G110
Software Windows 10 Pro
#3
How much time is spent doing the calculations and how much time is spent drawing? Comment out the draw calls and re-run. It may turn out that there's no amount of noticeable optimization left on your end and you'll have to take a different approach to your tile system.

Looking through the PyGame docs I see there's a new (still experimental) alternative to draw, gfxdraw. Try it out?

I was going to say thread it out because of how parallel the work is, but that won't help you on your Athlon64.

Anything else you can tell us about the game? Might be an easier to accomplish what you're after.
 

Aquinus

Resident Wat-man
Joined
Jan 28, 2012
Messages
10,404 (4.84/day)
Likes
5,486
Location
Concord, NH
System Name Kratos
Processor Intel Core i7 3930k @ 4.2Ghz
Motherboard ASUS P9X79 Deluxe
Cooling Zalman CPNS9900MAX 130mm
Memory G.Skill DDR3-2133, 16gb (4x4gb) @ 9-11-10-28-108-1T 1.65v
Video Card(s) MSI AMD Radeon R9 390 GAMING 8GB @ PCI-E 3.0
Storage 2x120Gb SATA3 Corsair Force GT Raid-0, 4x1Tb RAID-5, 1x500GB
Display(s) 1x LG 27UD69P (4k), 2x Dell S2340M (1080p)
Case Antec 1200
Audio Device(s) Onboard Realtek® ALC898 8-Channel High Definition Audio
Power Supply Seasonic 1000-watt 80 PLUS Platinum
Mouse Logitech G602
Keyboard Rosewill RK-9100
Software Ubuntu 17.10
Benchmark Scores Benchmarks aren't everything.
#4
You know, as long as the viewport position and zoom doesn't change, you can use the already calculated polys on each tile. Then only when the position or zoom changes you can recalculate. You will need to watch the posx, posy, and zoom for changes, if none don't calculate, otherwise calculate. xB and xC can also be stored and only recalculated if posx changes instead of calculating it every time. yA and yD can also be stored and only recalculated if zoom and posy change (since changes to posx doesn't impact these calculations.)

What I would do is keep track of the "state" of posx, posy, and zoom so you don't have to calculate more than you have to because you should only recalculate if you're:
A: running out of memory and can't store everything.
B: if any of the variable for the calculation that get used have changed.

So you need some variables like last_posx, last_posy, and last_zoom, and base your calculations on the difference between the last_ variable and the current one. That would speed up calculations when the viewport doesn't change. You can try and make this multithreaded as well, because this kind of workload is extremely parallel. I would recommend a couple of worker threads that work through the calculations and to store them and a single thread to actually render the polys of the tiles.

I don't know what else I can say*without actually trying to implement it. I hope that was of some use to you.
 
Joined
Feb 18, 2010
Messages
1,715 (0.60/day)
Likes
408
System Name Eldritch
Processor AMD Ryzen 5 1500X
Motherboard MSI B350 PC Mate
Cooling Satan's butthole after going to Taco Bell
Memory 16 GB G.Skill Flare X
Video Card(s) nVidia (Gigabyte) GT 740 2GB
Storage 80 GB IBM, 2 TB WD Green
Display(s) Dell 2007WFP
Software Debian Buster
#5
Minimize your updates to only include data that requires updating.
That's what

Code:
for tile in tileset:
        verts = tile.verts
        xB = verts[1][0]*mul+posx
        if xB > 0:#Maybe check Y values first?
            xC = verts[4][0]*mul+posx
            if xC < MODE[0]:#Width
                yA = verts[0][1]*zoom+posy
                if yA > 0:
                    yD = verts[3][1]*zoom+posy
                    if yD < MODE[1]:#Height
is mostly for.

How much time is spent doing the calculations and how much time is spent drawing? Comment out the draw calls and re-run. It may turn out that there's no amount of noticeable optimization left on your end and you'll have to take a different approach to your tile system.

Looking through the PyGame docs I see there's a new (still experimental) alternative to draw, gfxdraw. Try it out?

I was going to say thread it out because of how parallel the work is, but that won't help you on your Athlon64.

Anything else you can tell us about the game? Might be an easier to accomplish what you're after.
I'm not sure whether you mean what kind of game it is or the technical stuff, so I'll go for all of it. At the moment it's just an engine (as in, there's no campaign), it's meant to be used for turn-based RPG games, and it uses hexes as tiles. There are a few screenshots of it: a small map without gridspaces and a big map with gridspaces, I'm currently benching it with the big one (although I changed the terrain so that all the outside ones are water instead of dirt because dirt looked ugly). I'm currently using a big dictionary to store the info about the tiles, which (at the moment) include attributes for where the vertices are and what terrain the tile is. I'm also trying to keep the graphics system and the game engine itself as separate as possible so that should I ever actually get good at this I can build better (maybe even 3D, the game engine supports it) graphics systems and just shove them in there (or give people an option between the two).

Most of the actual "game" (rules, monsters, stats, skills, etc) will be defined by the campaign, and the one I'm thinking about building around it will be based on Pathfinder. I'm currently think about a free-roaming game (pronounced "I don't have a plot yet"). I'm also thinking about making it more mature (this'll go awesome with the '93 era graphics system) so you or villains or whoever can have sex, rob people, raze cities, kill kids, kidnap kids (and maybe ransom them), rape, torture, slavery, racism, the whole bit (I'm not gonna make you do any of it, but there's a really good chance you'll come across it). I'm also trying to make it quite big, with lots of societies each with their own laws, flaws, religions, government, people etc., etc.

You know, as long as the viewport position and zoom doesn't change, you can use the already calculated polys on each tile. Then only when the position or zoom changes you can recalculate. You will need to watch the posx, posy, and zoom for changes, if none don't calculate, otherwise calculate. xB and xC can also be stored and only recalculated if posx changes instead of calculating it every time. yA and yD can also be stored and only recalculated if zoom and posy change (since changes to posx doesn't impact these calculations.)

What I would do is keep track of the "state" of posx, posy, and zoom so you don't have to calculate more than you have to because you should only recalculate if you're:
A: running out of memory and can't store everything.
B: if any of the variable for the calculation that get used have changed.

So you need some variables like last_posx, last_posy, and last_zoom, and base your calculations on the difference between the last_ variable and the current one. That would speed up calculations when the viewport doesn't change.
I already did something like that (it was tied to the zoom in/out and move left/right/up/down controls), but it just recalculated everything (I just had an UPDATE variable). I never came up with the idea that Xs and Ys could stay the same (to be fair, I was using zooming as a benchmark anyways, so it probably wouldn't have helped too much).

You can try and make this multithreaded as well, because this kind of workload is extremely parallel. I would recommend a couple of worker threads that work through the calculations and to store them and a single thread to actually render the polys of the tiles.

I don't know what else I can say*without actually trying to implement it. I hope that was of some use to you.
I was thinking about that last night, but as Jizzler pointed out, my current CPU is single core (and knowing Python, making it multithreaded would likely hurt my performance). But I'm sure I could come up with something like:
Code:
if MULTITHREADED:
    sets = []
    for i in range(len(SUBPROCESSES)):
        sets.append(split up tileset)
    for i in SUBPROCESSES:
        SUBPROCESSES[i].run(drawhex, something something)
else:
    drawhex(tileset)
And maybe change it up some so that the threads do the calculations of where the vertices are and the main thread actually does the drawing.


EDIT:
It turns out that drawing the tiles is about half the work.
 
Last edited:

Aquinus

Resident Wat-man
Joined
Jan 28, 2012
Messages
10,404 (4.84/day)
Likes
5,486
Location
Concord, NH
System Name Kratos
Processor Intel Core i7 3930k @ 4.2Ghz
Motherboard ASUS P9X79 Deluxe
Cooling Zalman CPNS9900MAX 130mm
Memory G.Skill DDR3-2133, 16gb (4x4gb) @ 9-11-10-28-108-1T 1.65v
Video Card(s) MSI AMD Radeon R9 390 GAMING 8GB @ PCI-E 3.0
Storage 2x120Gb SATA3 Corsair Force GT Raid-0, 4x1Tb RAID-5, 1x500GB
Display(s) 1x LG 27UD69P (4k), 2x Dell S2340M (1080p)
Case Antec 1200
Audio Device(s) Onboard Realtek® ALC898 8-Channel High Definition Audio
Power Supply Seasonic 1000-watt 80 PLUS Platinum
Mouse Logitech G602
Keyboard Rosewill RK-9100
Software Ubuntu 17.10
Benchmark Scores Benchmarks aren't everything.
#6
I already did something like that (it was tied to the zoom in/out and move left/right/up/down controls), but it just recalculated everything (I just had an UPDATE variable). I never came up with the idea that Xs and Ys could stay the same (to be fair, I was using zooming as a benchmark anyways, so it probably wouldn't have helped too much).
The issue with having an update variable is that you have to do the checks and calculations anyways. You want to be able to compare the raw data and use that to determine if an update is required. That way you don't need to do this extra work.

Could you get the previous posx posy, and zoom variables from the last frame sent to the next frame to compare? If you can you can find out what needs to be updated:

If posx or mul changes update:
xA, xB, and xC

If posy or zoom changes update:
yA, yB, yC, and yD

if nothing changes use the already stored polys. The only downfall of this is that you need to store all of those variables.

Is it possible to provide a little more of the project you're working on? It might help us to get a wider perspective and to know what you have available to you before drawhex gets called because you might have data that could help you do less floating point math (which is reasonably slower than integer math and comparisons.)
 
Joined
Feb 18, 2010
Messages
1,715 (0.60/day)
Likes
408
System Name Eldritch
Processor AMD Ryzen 5 1500X
Motherboard MSI B350 PC Mate
Cooling Satan's butthole after going to Taco Bell
Memory 16 GB G.Skill Flare X
Video Card(s) nVidia (Gigabyte) GT 740 2GB
Storage 80 GB IBM, 2 TB WD Green
Display(s) Dell 2007WFP
Software Debian Buster
#7
I tried gfxdraw and I'm not sure if it's faster (it uses a different argument order, so I had to put an if statement to a global variable - globals are slow), but it looks significantly nicer so I think I'll use it anyway.

The issue with having an update variable is that you have to do the checks and calculations anyways. You want to be able to compare the raw data and use that to determine if an update is required. That way you don't need to do this extra work.
No, no, no. I made the zoom/move controls turn the UPDATE variable on, and during the loop it checks if UPDATE is True -i f it is, it calculates/draws everything.

Could you get the previous posx posy, and zoom variables from the last frame sent to the next frame to compare? If you can you can find out what needs to be updated:

If posx or mul changes update:
xA, xB, and xC

If posy or zoom changes update:
yA, yB, yC, and yD
Sure, shouldn't be too hard.

if nothing changes use the already stored polys. The only downfall of this is that you need to store all of those variables.
It doesn't calculate or draw anything unless UPDATE is True. I just update the display (without changing it's contents) so Windows doesn't say it isn't responding.

Is it possible to provide a little more of the project you're working on? It might help us to get a wider perspective and to know what you have available to you before drawhex gets called because you might have data that could help you do less floating point math (which is reasonably slower than integer math and comparisons.)
Here's the current source. It's in rough shape (there are a few things I should get busy deleting).


EDIT:
I think I'm going to just use pygame.gfxdraw instead of pygame.draw, so the current source will be a little out dated.
 
Last edited:

Kreij

Senior Monkey Moderator
Staff member
Joined
Feb 6, 2007
Messages
13,817 (3.48/day)
Likes
5,524
Location
Cheeseland (Wisconsin, USA)
Processor Intel Core 2 Quad QX9650 Extreme @ 3.0 GHz
Motherboard Asus Rampage Formula
Cooling ZeroTherm Nirvana NV120 Premium
Memory 8GB (4 x 2GB) Corsair Dominator PC2-8500
Video Card(s) 2 x Sapphire Radeon HD6970
Storage 2 x Seagate Barracuda 320GB in RAID 0
Display(s) Dell 3007WFP 30" LCD (2560 x 1600)
Case Thermaltake Armor w/ 250mm Side Fan
Audio Device(s) SupremeFX 8ch Audio
Power Supply Thermaltake Toughpower 750W Modular
Software Win8 Pro x64 / Cat 12.10
#8
Great job, HR, but after looking at the pygame docs your going to hit the wall real soon.
Stop now and switch to a language that supports poly and model instancing, has full matrice API support (translation, tranformation, etc.) and fully utilizes HLSL.

Yes, it has a steep learning curve and will make your brain hurt. Yes, it will be worth it.

I'm in no way bashing your code or anything, but in a short time you are going to reach a point of no-can-do (or crazy hard to do) with pygame and delaying the move to something else will not make things any easier or give you more insight into writing a solid engine.

Just my humble opinion. :)

Code on :rockout:
 
Joined
Feb 18, 2010
Messages
1,715 (0.60/day)
Likes
408
System Name Eldritch
Processor AMD Ryzen 5 1500X
Motherboard MSI B350 PC Mate
Cooling Satan's butthole after going to Taco Bell
Memory 16 GB G.Skill Flare X
Video Card(s) nVidia (Gigabyte) GT 740 2GB
Storage 80 GB IBM, 2 TB WD Green
Display(s) Dell 2007WFP
Software Debian Buster
#9
But..... look how beautiful it is:



You gotta admit, that's pretty sexy.
 
Joined
Sep 3, 2010
Messages
3,443 (1.29/day)
Likes
1,685
Location
NL, Europe
Processor Intel Core i5-4460
Motherboard Gigabyte GA-Z97-D3H
Cooling Arctic Freezer i11
Memory Crucial Ballistix Sport, DDR3-1600, 2x4 GB kit
Video Card(s) Sapphire Radeon R9 270X Vapor-X
Storage Kingston SSDNow V300 (120GB) + Seagate Barracuda 7200.14 (1TB)
Display(s) AOC G2260VWQ6 | Acer AL1916 (in reserve)
Case Cooler Maste Centurion 5
Audio Device(s) integrated
Power Supply Seasonic G450
Mouse Logitech G500
Keyboard Qpad MK-50
Software Windows 10
#10
Take a look at the source code of the F/OSS game "The Battle for Wesnoth" which is similar to what you seem to want to do: www.wesnoth.org. It is written in a C variety though, AFAIK.
 
Joined
Feb 18, 2010
Messages
1,715 (0.60/day)
Likes
408
System Name Eldritch
Processor AMD Ryzen 5 1500X
Motherboard MSI B350 PC Mate
Cooling Satan's butthole after going to Taco Bell
Memory 16 GB G.Skill Flare X
Video Card(s) nVidia (Gigabyte) GT 740 2GB
Storage 80 GB IBM, 2 TB WD Green
Display(s) Dell 2007WFP
Software Debian Buster
#11
If it's C I'm not exactly looking forward to it, but I'll take a stab anyways.

Anyways I had dinner and it dawned on me that any given vertex can have up to 3 tiles connected to it, and I'm calculating each vertex every time it appears in a tile. So I'll see what I can do about that (I'll probably be gone most of tomorrow though).
 
Joined
Jul 23, 2011
Messages
1,555 (0.66/day)
Likes
1,459
Location
Kaunas, Lithuania
System Name Eternal WIP ][ HP ProLiant server blade
Processor AMD FX-8320 @ 4.4/4.1 GHz ][ 2x Intel Xeon L5520 @ 2.27GHz
Motherboard Asus Crosshair V Formula-Z ][ -
Cooling Corsair H55 ][ Stock
Memory 2x4GB Kingston HyperX Genesis @ 1866MHz ][ 4x4 GiB Hynix @ 1333 MHz; ECC on
Video Card(s) 2x MSI GeForce GTX 770 DirectCU II OC ][ None
Storage 1TB WD Black + 1.5TB WD Green + 750GB Samsung + 64GB OCZ Agility 4 ][ 3x 1 TB Hitachi
Display(s) Asus VG278H + Asus VH226H ][ None
Case Antec Nine Hundred ][ it's a server blade, lol
Audio Device(s) Supreme FX II (Integrated); Using optical S/PDIF output ][ none
Power Supply Corsair AX1200i ][ [stock]
Software Gentoo Linux ][ Linux Mint 16
Benchmark Scores 65970 BogoMIPS. Ha. Ha. Ha. >=|
#12
How 'bout a little "cheating"? ;)
I mean, LOD. For example, when zoomed out enough, draw 1 "bigger" tile 'stead of 4. Of course, You would lose accuracy of what's visible. Although, If at one point, You would use a map, that when zoomed out completely, would have more than 1 tile/screen_pixel, it wouldn't make that much of visual difference anyway. :laugh:
 
Joined
Feb 18, 2010
Messages
1,715 (0.60/day)
Likes
408
System Name Eldritch
Processor AMD Ryzen 5 1500X
Motherboard MSI B350 PC Mate
Cooling Satan's butthole after going to Taco Bell
Memory 16 GB G.Skill Flare X
Video Card(s) nVidia (Gigabyte) GT 740 2GB
Storage 80 GB IBM, 2 TB WD Green
Display(s) Dell 2007WFP
Software Debian Buster
#13
Since it uses hexes, that would only get rid of 2 vertices for every 17 - not exactly a huge difference.
 
Joined
Jul 23, 2011
Messages
1,555 (0.66/day)
Likes
1,459
Location
Kaunas, Lithuania
System Name Eternal WIP ][ HP ProLiant server blade
Processor AMD FX-8320 @ 4.4/4.1 GHz ][ 2x Intel Xeon L5520 @ 2.27GHz
Motherboard Asus Crosshair V Formula-Z ][ -
Cooling Corsair H55 ][ Stock
Memory 2x4GB Kingston HyperX Genesis @ 1866MHz ][ 4x4 GiB Hynix @ 1333 MHz; ECC on
Video Card(s) 2x MSI GeForce GTX 770 DirectCU II OC ][ None
Storage 1TB WD Black + 1.5TB WD Green + 750GB Samsung + 64GB OCZ Agility 4 ][ 3x 1 TB Hitachi
Display(s) Asus VG278H + Asus VH226H ][ None
Case Antec Nine Hundred ][ it's a server blade, lol
Audio Device(s) Supreme FX II (Integrated); Using optical S/PDIF output ][ none
Power Supply Corsair AX1200i ][ [stock]
Software Gentoo Linux ][ Linux Mint 16
Benchmark Scores 65970 BogoMIPS. Ha. Ha. Ha. >=|
#14
1 in place of 4 was an example. You can do various levels of LOD. That's why its 'levels of detail' ;]
If You can pull this off correctly, even as little as reducing by 2 vertices for every 17 can make a large difference when You have a sh*tload of tiles. Also, If I understand it correctly, it would drastically reduce gfxdraw calls. I think You really do want to reduce gfxdraw by as much as possible. That was the idea in the first place, not the vertices.
And also the most important thing: right now You only have tiles. When those tiles start holding something more than 'only themselves' (i.e.: objects 'n stuff). Then - not drawing and not even assessing those tiles in the first place, is probably going to be a huge speed-up at that point of development.

[humble tone]I suppose You do realize that the more You optimize, the less You are able to shave off with each optimization.[/humble tone]
 

Aquinus

Resident Wat-man
Joined
Jan 28, 2012
Messages
10,404 (4.84/day)
Likes
5,486
Location
Concord, NH
System Name Kratos
Processor Intel Core i7 3930k @ 4.2Ghz
Motherboard ASUS P9X79 Deluxe
Cooling Zalman CPNS9900MAX 130mm
Memory G.Skill DDR3-2133, 16gb (4x4gb) @ 9-11-10-28-108-1T 1.65v
Video Card(s) MSI AMD Radeon R9 390 GAMING 8GB @ PCI-E 3.0
Storage 2x120Gb SATA3 Corsair Force GT Raid-0, 4x1Tb RAID-5, 1x500GB
Display(s) 1x LG 27UD69P (4k), 2x Dell S2340M (1080p)
Case Antec 1200
Audio Device(s) Onboard Realtek® ALC898 8-Channel High Definition Audio
Power Supply Seasonic 1000-watt 80 PLUS Platinum
Mouse Logitech G602
Keyboard Rosewill RK-9100
Software Ubuntu 17.10
Benchmark Scores Benchmarks aren't everything.
#15
Since it uses hexes, that would only get rid of 2 vertices for every 17 - not exactly a huge difference.
12% is actually reasonable imho.
 
Joined
Jul 23, 2011
Messages
1,555 (0.66/day)
Likes
1,459
Location
Kaunas, Lithuania
System Name Eternal WIP ][ HP ProLiant server blade
Processor AMD FX-8320 @ 4.4/4.1 GHz ][ 2x Intel Xeon L5520 @ 2.27GHz
Motherboard Asus Crosshair V Formula-Z ][ -
Cooling Corsair H55 ][ Stock
Memory 2x4GB Kingston HyperX Genesis @ 1866MHz ][ 4x4 GiB Hynix @ 1333 MHz; ECC on
Video Card(s) 2x MSI GeForce GTX 770 DirectCU II OC ][ None
Storage 1TB WD Black + 1.5TB WD Green + 750GB Samsung + 64GB OCZ Agility 4 ][ 3x 1 TB Hitachi
Display(s) Asus VG278H + Asus VH226H ][ None
Case Antec Nine Hundred ][ it's a server blade, lol
Audio Device(s) Supreme FX II (Integrated); Using optical S/PDIF output ][ none
Power Supply Corsair AX1200i ][ [stock]
Software Gentoo Linux ][ Linux Mint 16
Benchmark Scores 65970 BogoMIPS. Ha. Ha. Ha. >=|
#16
How's Your progress?
You just went silent here. Yet, it would really be nice to hear how You are doing there with that engine!