• Welcome to TechPowerUp Forums, Guest! Please check out our forum guidelines for info related to our community.

Optimizing Python game

Joined
Feb 18, 2010
Messages
1,850 (0.36/day)
System Name Eldritch
Processor AMD Ryzen 5 5800X3D
Motherboard ASUS TUF X570 Pro Wifi
Cooling Satan's butthole after going to Taco Bell
Memory 64 GB G.Skill TridentZ
Video Card(s) Vega 56
Storage 6*8TB Western Digital Blues in RAID 6, 2*512 GB Samsung 960 Pros
Display(s) Acer CB281HK
Case Phanteks Enthoo Pro PH-ES614P_BK
Audio Device(s) ASUS Xonar DX
Power Supply EVGA Supernova 750 G2
Mouse Razer Viper 8K
Software Debian Bullseye
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
26,259 (4.65/day)
Location
IA, USA
System Name BY-2021
Processor AMD Ryzen 7 5800X (65w eco profile)
Motherboard MSI B550 Gaming Plus
Cooling Scythe Mugen (rev 5)
Memory 2 x Kingston HyperX DDR4-3200 32 GiB
Video Card(s) AMD Radeon RX 7900 XT
Storage Samsung 980 Pro, Seagate Exos X20 TB 7200 RPM
Display(s) Nixeus NX-EDG274K (3840x2160@144 DP) + Samsung SyncMaster 906BW (1440x900@60 HDMI-DVI)
Case Coolermaster HAF 932 w/ USB 3.0 5.25" bay + USB 3.2 (A+C) 3.5" bay
Audio Device(s) Realtek ALC1150, Micca OriGen+
Power Supply Enermax Platimax 850w
Mouse Nixeus REVEL-X
Keyboard Tesoro Excalibur
Software Windows 10 Home 64-bit
Benchmark Scores Faster than the tortoise; slower than the hare.
Minimize your updates to only include data that requires updating.
 
Joined
Aug 10, 2007
Messages
4,267 (0.70/day)
Location
Sanford, 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
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
13,147 (2.96/day)
Location
Concord, NH, USA
System Name Apollo
Processor Intel Core i9 9880H
Motherboard Some proprietary Apple thing.
Memory 64GB DDR4-2667
Video Card(s) AMD Radeon Pro 5600M, 8GB HBM2
Storage 1TB Apple NVMe, 4TB External
Display(s) Laptop @ 3072x1920 + 2x LG 5k Ultrafine TB3 displays
Case MacBook Pro (16", 2019)
Audio Device(s) AirPods Pro, Sennheiser HD 380s w/ FIIO Alpen 2, or Logitech 2.1 Speakers
Power Supply 96w Power Adapter
Mouse Logitech MX Master 3
Keyboard Logitech G915, GL Clicky
Software MacOS 12.1
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,850 (0.36/day)
System Name Eldritch
Processor AMD Ryzen 5 5800X3D
Motherboard ASUS TUF X570 Pro Wifi
Cooling Satan's butthole after going to Taco Bell
Memory 64 GB G.Skill TridentZ
Video Card(s) Vega 56
Storage 6*8TB Western Digital Blues in RAID 6, 2*512 GB Samsung 960 Pros
Display(s) Acer CB281HK
Case Phanteks Enthoo Pro PH-ES614P_BK
Audio Device(s) ASUS Xonar DX
Power Supply EVGA Supernova 750 G2
Mouse Razer Viper 8K
Software Debian Bullseye
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
13,147 (2.96/day)
Location
Concord, NH, USA
System Name Apollo
Processor Intel Core i9 9880H
Motherboard Some proprietary Apple thing.
Memory 64GB DDR4-2667
Video Card(s) AMD Radeon Pro 5600M, 8GB HBM2
Storage 1TB Apple NVMe, 4TB External
Display(s) Laptop @ 3072x1920 + 2x LG 5k Ultrafine TB3 displays
Case MacBook Pro (16", 2019)
Audio Device(s) AirPods Pro, Sennheiser HD 380s w/ FIIO Alpen 2, or Logitech 2.1 Speakers
Power Supply 96w Power Adapter
Mouse Logitech MX Master 3
Keyboard Logitech G915, GL Clicky
Software MacOS 12.1
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,850 (0.36/day)
System Name Eldritch
Processor AMD Ryzen 5 5800X3D
Motherboard ASUS TUF X570 Pro Wifi
Cooling Satan's butthole after going to Taco Bell
Memory 64 GB G.Skill TridentZ
Video Card(s) Vega 56
Storage 6*8TB Western Digital Blues in RAID 6, 2*512 GB Samsung 960 Pros
Display(s) Acer CB281HK
Case Phanteks Enthoo Pro PH-ES614P_BK
Audio Device(s) ASUS Xonar DX
Power Supply EVGA Supernova 750 G2
Mouse Razer Viper 8K
Software Debian Bullseye
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
Joined
Feb 6, 2007
Messages
13,817 (2.21/day)
Location
Cheeseland (Wisconsin, USA)
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,850 (0.36/day)
System Name Eldritch
Processor AMD Ryzen 5 5800X3D
Motherboard ASUS TUF X570 Pro Wifi
Cooling Satan's butthole after going to Taco Bell
Memory 64 GB G.Skill TridentZ
Video Card(s) Vega 56
Storage 6*8TB Western Digital Blues in RAID 6, 2*512 GB Samsung 960 Pros
Display(s) Acer CB281HK
Case Phanteks Enthoo Pro PH-ES614P_BK
Audio Device(s) ASUS Xonar DX
Power Supply EVGA Supernova 750 G2
Mouse Razer Viper 8K
Software Debian Bullseye
But..... look how beautiful it is:



You gotta admit, that's pretty sexy.
 
Joined
Sep 3, 2010
Messages
3,527 (0.71/day)
Location
Netherlands
System Name desktop | Odroid N2+ |
Processor AMD Ryzen 5 3600 | Amlogic S922X |
Motherboard Gigabyte B550M DS3H |Odroid N2+ |
Cooling Inter-Tech Argus SU-200, 3x Arctic P12 case fans | stock heatsink + fan |
Memory Gskill Aegis DDR4 32GB | 4 GB DDR4 |
Video Card(s) Sapphire Pulse RX 6600 (8GB) | Arm Mali G52 |
Storage SK Hynix SSD 240GB, Samsung 840 EVO 250 GB, Toshiba DT01ACA100 1T | Samsung 850 Evo 500GB |
Display(s) AOC G2260VWQ6 | LG 24MT57D |
Case Asus Prime 201 | Stock case (black version) |
Audio Device(s) integrated
Power Supply BeQuiet! Pure Power 11 400W | 12v barrel jack |
Mouse Logitech G500 |Steelseries Rival 300
Keyboard Qpad MK-50 (Cherry MX brown)| Blaze Keyboard
Software Windows 10, Various Linux distros | Gentoo Linux
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,850 (0.36/day)
System Name Eldritch
Processor AMD Ryzen 5 5800X3D
Motherboard ASUS TUF X570 Pro Wifi
Cooling Satan's butthole after going to Taco Bell
Memory 64 GB G.Skill TridentZ
Video Card(s) Vega 56
Storage 6*8TB Western Digital Blues in RAID 6, 2*512 GB Samsung 960 Pros
Display(s) Acer CB281HK
Case Phanteks Enthoo Pro PH-ES614P_BK
Audio Device(s) ASUS Xonar DX
Power Supply EVGA Supernova 750 G2
Mouse Razer Viper 8K
Software Debian Bullseye
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,586 (0.34/day)
Location
Kaunas, Lithuania
System Name my box
Processor AMD Ryzen 9 5950X
Motherboard ASRock Taichi x470 Ultimate
Cooling NZXT Kraken x72
Memory 2×16GiB @ 3200MHz, some Corsair RGB led meme crap
Video Card(s) AMD [ASUS ROG STRIX] Radeon RX Vega64 [OC Edition]
Storage Samsung 970 Pro && 2× Seagate IronWolf Pro 4TB in Raid 1
Display(s) Asus VG278H + Asus VH226H
Case Fractal Design Define R6 Black TG
Audio Device(s) Using optical S/PDIF output lol
Power Supply Corsair AX1200i
Mouse Razer Naga Epic
Keyboard Keychron Q1
Software Funtoo Linux
Benchmark Scores 217634.24 BogoMIPS
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,850 (0.36/day)
System Name Eldritch
Processor AMD Ryzen 5 5800X3D
Motherboard ASUS TUF X570 Pro Wifi
Cooling Satan's butthole after going to Taco Bell
Memory 64 GB G.Skill TridentZ
Video Card(s) Vega 56
Storage 6*8TB Western Digital Blues in RAID 6, 2*512 GB Samsung 960 Pros
Display(s) Acer CB281HK
Case Phanteks Enthoo Pro PH-ES614P_BK
Audio Device(s) ASUS Xonar DX
Power Supply EVGA Supernova 750 G2
Mouse Razer Viper 8K
Software Debian Bullseye
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,586 (0.34/day)
Location
Kaunas, Lithuania
System Name my box
Processor AMD Ryzen 9 5950X
Motherboard ASRock Taichi x470 Ultimate
Cooling NZXT Kraken x72
Memory 2×16GiB @ 3200MHz, some Corsair RGB led meme crap
Video Card(s) AMD [ASUS ROG STRIX] Radeon RX Vega64 [OC Edition]
Storage Samsung 970 Pro && 2× Seagate IronWolf Pro 4TB in Raid 1
Display(s) Asus VG278H + Asus VH226H
Case Fractal Design Define R6 Black TG
Audio Device(s) Using optical S/PDIF output lol
Power Supply Corsair AX1200i
Mouse Razer Naga Epic
Keyboard Keychron Q1
Software Funtoo Linux
Benchmark Scores 217634.24 BogoMIPS
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
13,147 (2.96/day)
Location
Concord, NH, USA
System Name Apollo
Processor Intel Core i9 9880H
Motherboard Some proprietary Apple thing.
Memory 64GB DDR4-2667
Video Card(s) AMD Radeon Pro 5600M, 8GB HBM2
Storage 1TB Apple NVMe, 4TB External
Display(s) Laptop @ 3072x1920 + 2x LG 5k Ultrafine TB3 displays
Case MacBook Pro (16", 2019)
Audio Device(s) AirPods Pro, Sennheiser HD 380s w/ FIIO Alpen 2, or Logitech 2.1 Speakers
Power Supply 96w Power Adapter
Mouse Logitech MX Master 3
Keyboard Logitech G915, GL Clicky
Software MacOS 12.1
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,586 (0.34/day)
Location
Kaunas, Lithuania
System Name my box
Processor AMD Ryzen 9 5950X
Motherboard ASRock Taichi x470 Ultimate
Cooling NZXT Kraken x72
Memory 2×16GiB @ 3200MHz, some Corsair RGB led meme crap
Video Card(s) AMD [ASUS ROG STRIX] Radeon RX Vega64 [OC Edition]
Storage Samsung 970 Pro && 2× Seagate IronWolf Pro 4TB in Raid 1
Display(s) Asus VG278H + Asus VH226H
Case Fractal Design Define R6 Black TG
Audio Device(s) Using optical S/PDIF output lol
Power Supply Corsair AX1200i
Mouse Razer Naga Epic
Keyboard Keychron Q1
Software Funtoo Linux
Benchmark Scores 217634.24 BogoMIPS
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!
 
Top