Mirage Source :: View topic - HUGE optimization

Quote:

The "engine" is essentially 15 (if that?) lines of dx surface initialization and some calls all over the place to looped texture painting. Explain how preventing tilesheet renders of 0,0 breaks the code in any way shape or form?

if you do not understand how it is an "engine", here is the walk through

It starts off by counting the number of graphics. Sprites, Items, etc, to dimension a set of arrays, using UDT, so it's variables can be referenced easier.
it looks like this

Code:

Private Type DD_BufferRec
    Surface As DirectDrawSurface7
    SurfDescription As DDSURFACEDESC2
    SurfTimer As Long
End Type

When a graphic is used, for example, you see a new NPC on a map and its sprite number 154. This "engine" automatically loads the correct graphic into memory with this sub

Code:

Public Sub InitDDSurf(FileName As String, ByRef DD_SurfBuffer As DD_BufferRec)

 ' ... lets ignore this stuff to save space and get straight to the bottom part

ErrorHandle:

    Select Case Err
        
        ' File not found
        Case 53
            MsgBox "missing file: " & FileName
            Call DestroyGame
        
        ' DirectDraw does not have enough memory to perform the operation.
        Case DDERR_OUTOFMEMORY
            MsgBox "Out of system memory"
            Call DestroyGame
            
        ' DirectDraw does not have enough display memory to perform the operation.
        Case DDERR_OUTOFVIDEOMEMORY
            Call DevMsg("Out of video memory, attempting to re-initialize using system memory", BrightRed)

            DDSD_Temp.ddsCaps.lCaps = DDSCAPS_OFFSCREENPLAIN Or DDSCAPS_SYSTEMMEMORY

            Call ReInitDD
End Sub

Instead of checking if the file exists every time, it just handles file not found error to improve performance of this often-called method.
Based on what you see above in the error handler, attempts to load all graphics into your video RAM, and then if there insufficient space, the "engine" re-initializes using system memory.

The Re-initialization function is pretty neat, because it handles nearly every type of potential crash, such as: changing resolution or color mode, a screensaver or a 3D fullscreen application starts to run.

But back to explaining how this is an "engine"

so after your graphic isn't being rendering anymore, its automatically unloaded from your RAM, this loop helps

Code:

        ' Check if surface is ready to be unloaded
        If tmr10000 < Tick Then
            ' Sprites
            For i = 1 To NumSprites
                Call DD_CheckSurfTimer(DDS_Sprite(i))
            Next
            
            ' Spells
            For i = 1 To NumSpells
                Call DD_CheckSurfTimer(DDS_Spell(i))
            Next
            
            ' Items
            For i = 1 To NumItems
                Call DD_CheckSurfTimer(DDS_Item(i))
            Next
            
            tmr10000 = Tick + 10000
        End If

Then, when we get to the rendering, there are wrapper methods that draw to pre-calculated positions, created to enhance the functionality of the "engine"

But anyway if you don't think its an engine, then its all good

but to the main issue at hand

if you are not drawing because ground = 0, in that location, it will keep the trash in the backbuffer from the previous frames, there's nothing that clears/refreshes your screen/buffer, so the "engine" is dependent on drawing "blank" tiles to refresh the entire backbuffer

if you do not understand, speak with Genusis for more information, he has proven to be knowledgeable with DirectDraw7, beta tested the MS4 DD7 rendering engine, and submitted bug reports.

Author:	GIAKEN [ Mon Apr 06, 2009 6:43 pm ]
Post subject:	HUGE optimization
Anybody ever notice something? The ground layer will draw, even if it's not set. To fix this, simply find where it's drawing: Code: Call DD_BltFast(MapTilePosition(X, Y).PosX, MapTilePosition(X, Y).PosY, DDS_Tile.Surface, MapTilePosition(X, Y).Ground, DDBLTFAST_WAIT) And replace it with this: Code: If Map.Tile(X, Y).Ground > 0 Then Call DD_BltFast(MapTilePosition(X, Y).PosX, MapTilePosition(X, Y).PosY, DDS_Tile.Surface, MapTilePosition(X, Y).Ground, DDBLTFAST_WAIT) End If My FPS went from 200 to nearly 500.

Author:	Sh4rk [ Mon Apr 06, 2009 7:30 pm ]
Post subject:	Re: HUGE optimization
Hey, I have searched : Code: rec.Top = (.Ground \ TILESHEET_WIDTH) * PIC_Y rec.Bottom = rec.Top + PIC_Y rec.Left = (.Ground Mod TILESHEET_WIDTH) * PIC_X rec.Right = rec.Left + PIC_X DDS_BackBuffer.BltFast X * PIC_X, Y * PIC_Y, DDS_Tile, rec, DDBLTFAST_WAIT But I have found nothing, except : Code: MapTilePosition(X, Y).Ground.Top = (Map.Tile(X, Y).Ground \ TILESHEET_WIDTH) * PIC_Y MapTilePosition(X, Y).Ground.Bottom = MapTilePosition(X, Y).Ground.Top + PIC_Y MapTilePosition(X, Y).Ground.Left = (Map.Tile(X, Y).Ground Mod TILESHEET_WIDTH) * PIC_X MapTilePosition(X, Y).Ground.Right = MapTilePosition(X, Y).Ground.Left + PIC_X In Public Sub CalcTilePositions() And i have modified this by : Code: If Map.Tile(X, Y).Ground > 0 Then MapTilePosition(X, Y).Ground.Top = (Map.Tile(X, Y).Ground \ TILESHEET_WIDTH) * PIC_Y MapTilePosition(X, Y).Ground.Bottom = MapTilePosition(X, Y).Ground.Top + PIC_Y MapTilePosition(X, Y).Ground.Left = (Map.Tile(X, Y).Ground Mod TILESHEET_WIDTH) * PIC_X MapTilePosition(X, Y).Ground.Right = MapTilePosition(X, Y).Ground.Left + PIC_X End If But, when you change map, it's not refresh the ground in a blank map, you see the ground of the other map..

Author:	GIAKEN [ Mon Apr 06, 2009 7:50 pm ]
Post subject:	Re: HUGE optimization
Oh... Well I haven't looked at the newest version yet. I will do that now... Alright updated.

Author:	Sh4rk [ Mon Apr 06, 2009 8:24 pm ]
Post subject:	Re: HUGE optimization
Ok, it's okay for FPS, i up to 800/900 but i have the same bug with no refresh of ground 0 ... Test to apply a blank tile or go on map 1 and warp on map 3, you will see what i mean... (sry for my bad english, i'm french ^^')

Author:	GIAKEN [ Mon Apr 06, 2009 8:34 pm ]
Post subject:	Re: HUGE optimization
If you didn't undo what I told you before then you need to do that.

Mirage Source http://www.miragesource.net/forums/

HUGE optimization http://www.miragesource.net/forums/viewtopic.php?f=184&t=5377	Page 1 of 38

Author:	doomJoost1 [ Mon Apr 06, 2009 10:06 pm ]
Post subject:	Re: HUGE optimization
Is this being done for fringe/mas as well? I guess the reason for this is that in most games, all floor tiles are covered, your huge FPS jump must've been an empty map. A good optimization, no doubt, but a huge one?

Author:	GIAKEN [ Mon Apr 06, 2009 10:45 pm ]
Post subject:	Re: HUGE optimization
Yeah I doubled my FPS...I count that as a huge optimization. Maybe not a lot of lines edited, but still none-the-less a huge optimization.

Author:	doomJoost1 [ Tue Apr 07, 2009 6:32 am ]
Post subject:	Re: HUGE optimization
But when all ground tiles are filled, like in most maps, the only effect is adding MAX_Y*MAX_X If statements, actually decreasing FPS. The more tiles you use, the less this works, and eventually this'll give a negative effect, with all ground tiles used. So I stand by original opinion, not huge ;p.

Author:	Labmonkey [ Tue Apr 07, 2009 12:50 pm ]
Post subject:	Re: HUGE optimization
Yea, I agree with joost. Your testing your optimization on a blank map. How many times are there blank maps in games? fill the ground layer with tiles and then check your fps.

Author:	genusis [ Tue Apr 07, 2009 2:37 pm ]
Post subject:	Re: HUGE optimization
OK i tested this, with it i get from 256 to 259 fps on a full map. without it i get 260 to 265 fps on a full map.

Author:	doomJoost1 [ Tue Apr 07, 2009 2:42 pm ]
Post subject:	Re: HUGE optimization
Aka, the first 2/260's second you see the map try out both options and see what gives high FPS.

Author:	james1992_2006 [ Fri Aug 07, 2009 6:08 pm ]
Post subject:	Re: HUGE optimization
because of the way the graphics rendering engine was implemented, not drawing "blank" ground tiles will cause visual artifacts. You're breaking the code and saying its an optimization...

Author:	Coke [ Fri Aug 07, 2009 11:34 pm ]
Post subject:	Re: HUGE optimization
james1992_2006 wrote: because of the way the graphics rendering engine was implemented, not drawing "blank" ground tiles will cause visual artifacts. You're breaking the code and saying its an optimization... The "engine" is essentially 15 (if that?) lines of dx surface initialization and some calls all over the place to looped texture painting. Explain how preventing tilesheet renders of 0,0 breaks the code in any way shape or form? You are talking bollocks. 0,0 is by default a black square, its only real purpose was discovered when Magnus wrote a tutorial that made the engine grab the first pixel in a tilesheet and set its RGB to your transparent colour. Tile 0,0 is ignored by every layer but ground. If you draw it onto the ground, you get black. It just so happens if we don't draw to the surface its black anyway - why draw to the surface if there is no visual change whatsoever? This breaks nothing, it speeds up drawing on empty maps your players won't ever see. Its an opimization. I see no problem with the code and no reason for this not to go into the next MS release - what I do see is a rather pointless post made by someone who doesn't know what they are talking about. If the removal of a ground tile leads to an artifact, you just need to clean the surface up instead of expecting vb6 to spoon feed you more than it already does, or throw in a single render of the 0,0 texture to effectively blank that tile location. If you are telling it not to redraw, its not going too. Redraw it ONCE to blank it under given circumstances, then don't draw it again. - its not rocket science. It makes sense that switching maps leaves all your now not drawing' ground tiles with an image of the last map. You've told the DX not to redraw so it isn't. Map Change and Deletion of Ground Tile in the editor are the only two circumstances I can think of where redraw logic is needed. Death fires off your warp, which fires off (essentially) a map change, so your basics are covered. As for the actual FPS increase, if you really want to go overkill on what is essentially a micro change, throw in an if statement that does a once over on the map for 0,0 on the ground layer - hell, throw in a number. If you only see a bonus if 100 out of your 700x700 tiles on the map are blank then just if statement the optimisation to only be active under that circumstance. Use some logic, Think ._. Coke

Author:	james1992_2006 [ Sun Aug 09, 2009 4:49 am ]
Post subject:	Re: HUGE optimization
Quote: The "engine" is essentially 15 (if that?) lines of dx surface initialization and some calls all over the place to looped texture painting. Explain how preventing tilesheet renders of 0,0 breaks the code in any way shape or form? if you do not understand how it is an "engine", here is the walk through It starts off by counting the number of graphics. Sprites, Items, etc, to dimension a set of arrays, using UDT, so it's variables can be referenced easier. it looks like this Code: Private Type DD_BufferRec Surface As DirectDrawSurface7 SurfDescription As DDSURFACEDESC2 SurfTimer As Long End Type When a graphic is used, for example, you see a new NPC on a map and its sprite number 154. This "engine" automatically loads the correct graphic into memory with this sub Code: Public Sub InitDDSurf(FileName As String, ByRef DD_SurfBuffer As DD_BufferRec) ' ... lets ignore this stuff to save space and get straight to the bottom part ErrorHandle: Select Case Err ' File not found Case 53 MsgBox "missing file: " & FileName Call DestroyGame ' DirectDraw does not have enough memory to perform the operation. Case DDERR_OUTOFMEMORY MsgBox "Out of system memory" Call DestroyGame ' DirectDraw does not have enough display memory to perform the operation. Case DDERR_OUTOFVIDEOMEMORY Call DevMsg("Out of video memory, attempting to re-initialize using system memory", BrightRed) DDSD_Temp.ddsCaps.lCaps = DDSCAPS_OFFSCREENPLAIN Or DDSCAPS_SYSTEMMEMORY Call ReInitDD End Sub Instead of checking if the file exists every time, it just handles file not found error to improve performance of this often-called method. Based on what you see above in the error handler, attempts to load all graphics into your video RAM, and then if there insufficient space, the "engine" re-initializes using system memory. The Re-initialization function is pretty neat, because it handles nearly every type of potential crash, such as: changing resolution or color mode, a screensaver or a 3D fullscreen application starts to run. But back to explaining how this is an "engine" so after your graphic isn't being rendering anymore, its automatically unloaded from your RAM, this loop helps Code: ' Check if surface is ready to be unloaded If tmr10000 < Tick Then ' Sprites For i = 1 To NumSprites Call DD_CheckSurfTimer(DDS_Sprite(i)) Next ' Spells For i = 1 To NumSpells Call DD_CheckSurfTimer(DDS_Spell(i)) Next ' Items For i = 1 To NumItems Call DD_CheckSurfTimer(DDS_Item(i)) Next tmr10000 = Tick + 10000 End If Then, when we get to the rendering, there are wrapper methods that draw to pre-calculated positions, created to enhance the functionality of the "engine" But anyway if you don't think its an engine, then its all good but to the main issue at hand if you are not drawing because ground = 0, in that location, it will keep the trash in the backbuffer from the previous frames, there's nothing that clears/refreshes your screen/buffer, so the "engine" is dependent on drawing "blank" tiles to refresh the entire backbuffer if you do not understand, speak with Genusis for more information, he has proven to be knowledgeable with DirectDraw7, beta tested the MS4 DD7 rendering engine, and submitted bug reports.

Author:	grimsk8ter11 [ Sun Aug 09, 2009 1:46 pm ]
Post subject:	Re: HUGE optimization
An engine is something that is transplantable with little or no effort ftw. If all of Mriages code was in a single class or module that provided an easy to use interface for doing most things DX then it would be an engine. Mirage provides no way for dynamics, everything is static, and we draw to a solid grid. I am not saying it could not be an engine with work, but it is not as it is. It is procedure calls embeded in code, no overlying structure. Mirage as a WHOLE is a 2d rpg engine, albiet quickly beocming more and more outdated. It can be transplanted and provide an eays way to make a 2D rpg. Every single "system" is not an engine.

Page 1 of 38	All times are UTC
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/

Author:	JokeofWeek [ Sun Aug 09, 2009 5:00 am ]
Post subject:	Re: HUGE optimization
Personally, I feel that the graphic drawing is already optimized, and doing this, although it could be a good idea on let's say indoor maps where there are lots of empty tiles, on most maps it is useless and will just lower your FPS. You have to remember that basically your game needs 32 FPS to look smooth, so if you get 900 instead of 850, it really won't make a big difference. The problem with this code is that there is potential for artifacts. Say for example a player walks near the empty tile and his name goes over it, there will be artifacts on that tile. If you REALLY want to optimize so badly, the best way would be to draw the entire map once and then only redraw the tiles that need to be drawn (for example where the sprite has been, etc.) You could potentially make a tile attribute No Redraw or something, for lets say a tile that you know the player will never get to but you can still see. This could be useful in situations like, for example, you are in a town and you can see the other side of the town wall, but you can't access it. That could be one approach.

Author:	Coke [ Sun Aug 09, 2009 9:11 am ]
Post subject:	Re: HUGE optimization
james1992_2006 wrote: Quote: The "engine" is essentially 15 (if that?) lines of dx surface initialization and some calls all over the place to looped texture painting. Explain how preventing tilesheet renders of 0,0 breaks the code in any way shape or form? if you do not understand how it is an "engine", here is the walk through It starts off by counting the number of graphics. Sprites, Items, etc, to dimension a set of arrays, using UDT, so it's variables can be referenced easier. it looks like this Code: Private Type DD_BufferRec Surface As DirectDrawSurface7 SurfDescription As DDSURFACEDESC2 SurfTimer As Long End Type When a graphic is used, for example, you see a new NPC on a map and its sprite number 154. This "engine" automatically loads the correct graphic into memory with this sub Code: Public Sub InitDDSurf(FileName As String, ByRef DD_SurfBuffer As DD_BufferRec) ' ... lets ignore this stuff to save space and get straight to the bottom part ErrorHandle: Select Case Err ' File not found Case 53 MsgBox "missing file: " & FileName Call DestroyGame ' DirectDraw does not have enough memory to perform the operation. Case DDERR_OUTOFMEMORY MsgBox "Out of system memory" Call DestroyGame ' DirectDraw does not have enough display memory to perform the operation. Case DDERR_OUTOFVIDEOMEMORY Call DevMsg("Out of video memory, attempting to re-initialize using system memory", BrightRed) DDSD_Temp.ddsCaps.lCaps = DDSCAPS_OFFSCREENPLAIN Or DDSCAPS_SYSTEMMEMORY Call ReInitDD End Sub Instead of checking if the file exists every time, it just handles file not found error to improve performance of this often-called method. Based on what you see above in the error handler, attempts to load all graphics into your video RAM, and then if there insufficient space, the "engine" re-initializes using system memory. The Re-initialization function is pretty neat, because it handles nearly every type of potential crash, such as: changing resolution or color mode, a screensaver or a 3D fullscreen application starts to run. But back to explaining how this is an "engine" so after your graphic isn't being rendering anymore, its automatically unloaded from your RAM, this loop helps Code: ' Check if surface is ready to be unloaded If tmr10000 < Tick Then ' Sprites For i = 1 To NumSprites Call DD_CheckSurfTimer(DDS_Sprite(i)) Next ' Spells For i = 1 To NumSpells Call DD_CheckSurfTimer(DDS_Spell(i)) Next ' Items For i = 1 To NumItems Call DD_CheckSurfTimer(DDS_Item(i)) Next tmr10000 = Tick + 10000 End If Then, when we get to the rendering, there are wrapper methods that draw to pre-calculated positions, created to enhance the functionality of the "engine" But anyway if you don't think its an engine, then its all good but to the main issue at hand if you are not drawing because ground = 0, in that location, it will keep the trash in the backbuffer from the previous frames, there's nothing that clears/refreshes your screen/buffer, so the "engine" is dependent on drawing "blank" tiles to refresh the entire backbuffer if you do not understand, speak with Genusis for more information, he has proven to be knowledgeable with DirectDraw7, beta tested the MS4 DD7 rendering engine, and submitted bug reports. Woah thanks for the lesson, I've never seen those bits of code before. Quote: if you are not drawing because ground = 0, in that location, it will keep the trash in the backbuffer from the previous frames, there's nothing that clears/refreshes your screen/buffer, so the "engine" is dependent on drawing "blank" tiles to refresh the entire backbuffer That's amazing. Its almost exactly what I have already said, only shorter. I feel enlightened. Personally, I don't qualify the ability to draw textures on a flat surface at designated places as an engine, if such simple procedures are now all called engines, then Mirage has about 200 engines in it. Next week can we please learn about the experience engine? Oh! Don't forget about the mana and hp engines too. If someone gave me a single class with Mirage's drawing code and told me it was a fantastic 2d graphics engine I'd punch them in the face as its just a very basic 2d implementation of directX. We draw it all to a grid (holy shit!) but that's about where the excitement ends.

Author:	GIAKEN [ Mon Aug 10, 2009 7:59 pm ]
Post subject:	Re: HUGE optimization
This method won't leave any artifacts on the back buffer...it doesn't clear by being drawn to, it's cleared by being filled with black before any of the drawing starts.

Author:	Toast [ Mon Aug 10, 2009 9:26 pm ]
Post subject:	Re: HUGE optimization
The simple if command Giaken has added is a "To draw or not to draw. That is the question."

Author:	Coke [ Mon Aug 10, 2009 10:56 pm ]
Post subject:	Re: HUGE optimization
Uh, didn't see that. This thread is full of failure (y).

Author:	wanai [ Wed Dec 01, 2021 10:38 am ]
Post subject:	Re: HUGE optimization
audiobookkeeper.rucottagenet.rueyesvision.rueyesvisions.comfactoringfee.rufilmzones.rugadwall.rugaffertape.rugageboard.rugagrule.rugallduct.rugalvanometric.rugangforeman.rugangwayplatform.rugarbagechute.rugardeningleave.rugascautery.rugashbucket.rugasreturn.rugatedsweep.rugaugemodel.rugaussianfilter.rugearpitchdiameter.ru geartreating.rugeneralizedanalysis.rugeneralprovisions.rugeophysicalprobe.rugeriatricnurse.rugetintoaflap.rugetthebounce.ruhabeascorpus.ruhabituate.ruhackedbolt.ruhackworker.ruhadronicannihilation.ruhaemagglutinin.ruhailsquall.ruhairysphere.ruhalforderfringe.ruhalfsiblings.ruhallofresidence.ruhaltstate.ruhandcoding.ruhandportedhead.ruhandradar.ruhandsfreetelephone.ru hangonpart.ruhaphazardwinding.ruhardalloyteeth.ruhardasiron.ruhardenedconcrete.ruharmonicinteraction.ruhartlaubgoose.ruhatchholddown.ruhaveafinetime.ruhazardousatmosphere.ruheadregulator.ruheartofgold.ruheatageingresistance.ruheatinggas.ruheavydutymetalcutting.rujacketedwall.rujapanesecedar.rujibtypecrane.rujobabandonment.rujobstress.rujogformation.rujointcapsule.rujointsealingmaterial.ru journallubricator.rujuicecatcher.rujunctionofchannels.rujusticiablehomicide.rujuxtapositiontwin.rukaposidisease.rukeepagoodoffing.rukeepsmthinhand.rukentishglory.rukerbweight.rukerrrotation.rukeymanassurance.rukeyserum.rukickplate.rukillthefattedcalf.rukilowattsecond.rukingweakfish.rukinozones.rukleinbottle.rukneejoint.ruknifesethouse.ruknockonatom.ruknowledgestate.ru kondoferromagnet.rulabeledgraph.rulaborracket.rulabourearnings.rulabourleasing.rulaburnumtree.rulacingcourse.rulacrimalpoint.rulactogenicfactor.rulacunarycoefficient.ruladletreatediron.rulaggingload.rulaissezaller.rulambdatransition.rulaminatedmaterial.rulammasshoot.rulamphouse.rulancecorporal.rulancingdie.rulandingdoor.rulandmarksensor.rulandreform.rulanduseratio.ru languagelaboratory.rulargeheart.rulasercalibration.rulaserlens.rulaserpulse.rulaterevent.rulatrinesergeant.rulayabout.ruleadcoating.ruleadingfirm.rulearningcurve.ruleaveword.rumachinesensible.rumagneticequator.rumagnetotelluricfield.rumailinghouse.rumajorconcern.rumammasdarling.rumanagerialstaff.rumanipulatinghand.rumanualchoke.rumedinfobooks.rump3lists.ru nameresolution.runaphtheneseries.runarrowmouthed.runationalcensus.runaturalfunctor.runavelseed.runeatplaster.runecroticcaries.runegativefibration.runeighbouringrights.ruobjectmodule.ruobservationballoon.ruobstructivepatent.ruoceanmining.ruoctupolephonon.ruofflinesystem.ruoffsetholder.ruolibanumresinoid.ruonesticket.rupackedspheres.rupagingterminal.rupalatinebones.rupalmberry.ru papercoating.ruparaconvexgroup.ruparasolmonoplane.ruparkingbrake.rupartfamily.rupartialmajorant.ruquadrupleworm.ruqualitybooster.ruquasimoney.ruquenchedspark.ruquodrecuperet.rurabbetledge.ruradialchaser.ruradiationestimator.rurailwaybridge.rurandomcoloration.rurapidgrowth.rurattlesnakemaster.rureachthroughregion.rureadingmagnifier.rurearchain.rurecessioncone.rurecordedassignment.ru rectifiersubstation.ruredemptionvalue.rureducingflange.rureferenceantigen.ruregeneratedprotein.rureinvestmentplan.rusafedrilling.rusagprofile.rusalestypelease.rusamplinginterval.rusatellitehydrology.ruscarcecommodity.ruscrapermat.ruscrewingunit.ruseawaterpump.rusecondaryblock.rusecularclergy.ruseismicefficiency.ruselectivediffuser.ruсайтsemifinishmachining.ruspicetrade.ruspysale.ru stungun.rutacticaldiameter.rutailstockcenter.rutamecurve.rutapecorrection.rutappingchuck.rutaskreasoningtechnicalgrade.rutelangiectaticlipoma.rutelescopicdamper.ruhttp://temperateclimate.rutemperedmeasure.rutenementbuilding.rutuchkasultramaficrock.ruultraviolettesting.ru

Author:	wanai [ Tue Jan 11, 2022 7:01 am ]
Post subject:	Re: HUGE optimization
Econ

Author:	wanai [ Tue Jan 11, 2022 7:02 am ]
Post subject:	Re: HUGE optimization
129.7

Author:	wanai [ Tue Jan 11, 2022 7:03 am ]
Post subject:	Re: HUGE optimization
Bett

Author:	wanai [ Tue Jan 11, 2022 7:04 am ]
Post subject:	Re: HUGE optimization
Bett