that's pretty lame 7-8 fps, while i assume it's caused because you run it in some kind of virtual windows (?).
i have no idea about linux, for sure it would be an option to windows but my recent notebook is to tight in space for a second OS that i could promise to compile a linux version in the near future. recently i didn't even compiled the win32 Pioneer i use still as base, this simply because it's not yet needed to reach the goals i have with modeling and scripting around the existing old release. once i'm satisfied with that i can caare again about this task (unfortunately i lost the source i used and worked with from around 2015, the source of alpha31 is still available one thing which hinders me also is that the third party sources for alpha31 are not longer available and what is used for the recent releases won't work for some tidbits and i have to reconstruct it and that's a piece of shit. i know this because i started to compile what i found still on my old machine, which like i said before also exhaustet it's last blue cloud of smoke, that was horrible but it happened now for the third time to me so it starts to get quite common. certainly backupdrives would prevent from such but one must have such a drive first. the HD isn't lost neither of the macbook nor from my old machine but also to recover what is on them i need to invest a little money. really such doesn't worries me anymore "shit happens - let's move on"). Fortunately i copied a lot of games and things to the notenbook before the powersupply brok, i assume it's the powersupply, i'm not sure i didn't opened it yet, but the smell of a burnt large eloctrolyte capacitor is pretty telling that it's the powersupply, assuming this my old machine should still run after fixing it but i lost patience with that and the notebook i use is that good i don't have much interest to fix the old crap. it became to me a waste of time in some way to fiddle around with broken or old hardware, i really like to use a computer and not to fix a broken one, perhaps when i'm in the mood for it, i fixed last year an even older one which i took home, it was left on the streetside so it asked for to be carried home. it was an easy thing to fix it, the processor cooling vent was stucked with dust. but it's besides an even older one as my machine and the powersupply i guess won't work it's a quite weak standard one. if im in the mood and recently i'm not (before i pick up the soldering iron for this task i would build a small composite out for my intellivision, that's more important to have for me and i made some theoretical suggests to that so i like to make proof what i claimed. it's because joe and the rest use a cheap pair of transistors for the purpose. in no way i like to say joe doesn't knows his job, apart from being a machine coder he's also a very good electronics engineer, the "LTO Flash" for my inty is his design, but dammit i guess it was my dead father who whispered in my ear "that isn't suitable for an amplifier it's ment for controllers or logical gates and controllers don't mind about oszillating or noise", the composite out is a sort of amplifier however oszillating of the circuit is to prevent at all cost and murphys law tells "every amplifier tends to oscillate and every oszillator tends to amplify". even the exact type i almost remembered immediatly, it surprised me myself. to invest 1$ more for a transistor isn't much money but it can have a big effect on the result. however i digged through the specifiction tables of the vendor and bingo i was right, theoretically at least).
what did i liked to say? transistors?
no!
back to fps and phoenix.
to be honest i reach also only about 15fps, but my notebook has not a good gpu i can't expect more of it and i guess neither i reach more running the official release, it runs quite good but i haven't yet compared the resulting framerate. pioneer makes the notebook sweat and the vent immediatly starts to go on maximum rpm when i start it. the fps i reach are about the same i reached with my old machine and a cheap gpu (yet another broken thingy and the one i used in the last years was an old one i removed from a piece of junk, but better a cheap graphics card as no graphics card.
but also i can't reach better esults with a thinner phoenix, when i started the project i limited it as much i could, near to no dynamic models, no textures, simple buildings, no pilots or extras like this even the adverts i banned, but the impact on framerate by slowly adding one after the other isn't worth to debate about, some single fps, but reaching a final framerate of 16 or 15 is pretty the same. yes the stations and especially, foremost the cities use a lot of fps. it's quite a riddle to me since it didn't gets much better if i use i.e no textures for the buildings. them are simply to many little buildings i guess and something like my "city tiles test" would probably reach better framerate even if the tiles are larger, but you won't use as many of them to display a reasonable looking city (i will see this project still lurks around on my HD so it won't be a big thing to test it). i assume the lmr uses more power to run but on the other hand all models are cached and they should run as fine as anykind of meshes/models. so said i don't reach much better framerates if i use wavefront objects instead of my scripted geometry, in the end it's pretty the same.
perhaps if i disable the random adverts it will be for some fps better, but don't expect no wonder i assume from your 5-6 to 8-10. i know that they eat up fps. but i re-enabled them and didn't noticed a big impact on my notebook. like i said perhaps from 16 down to 15.
similar settings similar fps, after a quick comparison i have to correct myself 20 to 24 for "Phoenix"
24 to 26 for the recent "Pioneer", settings are high, high, and medium for the cities (i ran it before high for the cities to that's why i reached before only 14 -16).
imho no big difference, and to be honest i expected better results of the recent release, at start i wondered "wow 32 fps!" switched to settings and noticed low, low, low "phew" i thought
i know the lmr is clumsy and i'm aware the 100s of functions (modeling helpers) won't make it better in performance neither my global material tables will help to run it faster (while if i remember that right tables are no big problem, they are cached on the hd and have no big impact on performance).
the city tiles could really help to gain fps, since you could run it at low and still get a large city as result. but there is a design problem with them. they look miserable if the terrain is hilly and horrible if it's a steep mountainside. if something like that should work at all the terrain for the cities must be flattened.
but guessing that i use so many new functions, new model functions, even "evil" global stuff i must say what i reach with the lmr isn't really bad. it has an impact on performance but it's for me not worth to think about to change to something else.
using a middle priced gpu it would certainly easy run at 30fps, guessing of that my notebook isn't ment for gaming purposes. it's just a notebook not even a laptop, if you know what i mean, calculators was almost bigger in the '80s and for sure bigger in the '70s

that thing isn't larger as a modern handy, nah ok as a tablet, it almost fits in my pocket.
i could spare most of the new functions for myself, but also to be honest for every function i made i remembered your troubles with the lmr and kept in mind to make it as easy as possible to create models with it, not that i expect that you will, just as a goal.
else i wouldn't have created something like a texturemapper, ok it teached me also many things about U,V, projection i didn't knew so well before, but the idea was really to simplify the model creation with the lmr.
and well
local scale = 1
local radius = 70*scale
local pixels = {25,50,100,0}
local texoffice1 = 'textures/office/office1.png'
local size = v(70,20,50)
--[[
"size" isn't only valid for the projection, as you can see
all vectors refere to this vector, if you change a value here
it will change the whole geometry in its dimensions, since the mapper referes
to the same values it will also keep the texture mapping.
mostly i've done this to fiddle around here with this so you can see
that the mapper is bound to the models extensions
--]]
local diagonal1 = Diagonal[3] -- simple but trustworthy "Diagonal" projection, requested from a table
local diagonal2 = Diagonal[5]
define_model('office1', { info = { scale = scale, lod_pixels = pixels, bounding_radius = radius, materials = {'concrete','aluminium','darkgrey','grey'}, tags = {'city_building'}, }, static = function(lod) local v0 = v(size.x/2,size.y + (size.y/25),size.z/2) --[[ "v0" is in the upper right corner (viewed from front) of the building and equals to the maximum extension of "U" & "V", here it's viewed from the front and the respective section of the texture map is as well right below half of the textures vertical extension thus the front projection hasn't to be moved, it's exactly in midst of the texture map, the building is designed for an easy use of the texturemapper, but if you start in the upper right corner it will always be "v0" which represents maximum "UV" and you can use "v0" for the position vector of the texturemapper. --]] -- building local v1 = mirx(v0) -- with mirx,miry,mirz you can easy flip coordinates local v2 = mirz(v0) local v3 = mirx(v2) local v4 = v(v0.x,size.y/25,v2.z) local v5 = mirx(v4) local v6 = v(v0.x,v4.y,v0.z) local v7 = mirx(v6) -- basement local v8 = v(v0.x,-size.y*2,v0.z) local v9 = mirx(v8) local v10 = v(v0.x,v8.y,v2.z) local v11 = mirx(v10) -- vectors for the cuboid function local cube1 = {v(size.x/4,v2.y,-size.z/4),v(size.x/8,size.y/6.25,size.z/4)} local cube2 = {v(size.x/4,v2.y,size.z/10),v(2,size.y/25,size.z/12.5)} local cube3 = {v(size.x/4,v2.y,size.z/3),v(2,size.y/25,size.z/12.5)} local cube4 = {v(-size.x/8,v2.y,0),v(size.x/8,size.y/6.25,size.z/4)} local front = texmapper(v0,size,v(0,0,1),v(1,-.25,1)) local top = texmapper(v0 + v(0,0,.5),size,v(0,1,0),v(1,1,-.49)) -- "+ 0.5" corrects --shifting of the "wrong" divisor "-.49" instead of "-.50" local side = texmapper(v0 + v(0,size.y*2,0),size,v(1,0,0),v(1,.25,1)) -- size.y*2 --shifts the geometry in the proper section of the map material('concrete') -- preset materials from a table, recognized by their names (name --is given) material('aluminium') material('darkgrey') material('grey') if lod == 1 then use_material('darkgrey') -- lod 1 buildings are visible but untextured thus this dark material end if lod > 1 then --top texture(texoffice1,top[1],top[2],top[3]) -- request values from texmapper output use_material('concrete') end quad(v2,v3,v1,v0) if lod > 1 then --front texture(texoffice1,front[1],front[2],front[3]) texture_glow(texoffice1glow) end quad(v0,v1,v7,v6) quad(v2,v4,v5,v3) if lod > 1 then --side texture(texoffice1,side[1],side[2],side[3]) end quad(v0,v6,v4,v2) quad(v1,v3,v5,v7) texture_glow(nil) if lod > 1 then --basement texture('textures/150.png',diagonal1[1],diagonal1[2],diagonal1[3]) -- request Diagonal projection from global table use_material('grey') --front quad(v6,v7,v9,v8) quad(v4,v10,v11,v5) --side quad(v4,v6,v8,v10) quad(v5,v11,v9,v7) if lod > 2 then -- extras -- cool function to easy texture a cuboid with the same texture from -- all sides, tiling or stretching is controlled with the last vector -- "divisor" texcuboid(cube1[1],cube1[2],'textures/113.png',v(1,.5,2)) texcuboid(cube4[1],cube4[2],'textures/113.png',v(1,.5,2)) if lod > 3 then use_material('aluminium') texture('textures/113.png',diagonal2[1],diagonal2[2],diagonal2[3]) cuboid(cube2[1],cube2[2]) cuboid(cube3[1],cube3[2]) end end end end, dynamic = function(lod) -- ventilator if lod > 3 then call_model('ventilator',v(-size.x/4,size.y +(size.y/25),-size.z/4),v(1,0,0),v(0,1,0),1) call_model('ventilator',v(-size.x/12,size.y +(size.y/25),-size.z/4),v(1,0,0),v(0,1,0),1) end end
})
it can't be much easier as this,
the whole vector listing is based on the size, change any of the size x,y, or z and the whole model will be build and textured reflecting this change.
i'm quite proud of that i can say.
one of the most helpful things i guess are the mirror functions, this let's you write vector listings in "no time", especially for something simple like a building.
the rest is except of the main building (5 quads) and the basement (another 4) all either a model function (cuboid, textured cuboid) or a sub-model of any kind (ventilator).
yes, the ventilators could spare another single fps if disabled

.
one could create a very very simple building with
texcuboid(v(0,0,0),v(30,10,20),'textures/any.png',v(0.0333,0.1,0.05))
and ready is the textured concrete cube (without any windows, or if the texture has windows on it the roof would have as well because "texcuboid" uses only one texture but maps it from all sides).
and i guess this is worth an impact of a few fps.