By your own definition it doesn't work accurately other on really slow machines. The previous test will always affect the result for the current test. Test1 will always have a higher FPS so the first readings for Test2 will be artificially higher than real - repeat this observation as it will hold true for each test
Recent community posts
Yep, the start was screwing up the first reading. Numbers look good now...
Think it'll need a lot more vertices/lights to hit 60fps :)
Compare the above to the APU - an AMD 610M - part of the 7745HX CPU in my laptop...
Laptop used for reference - https://www.lenovo.com/gb/en/p/laptops/legion-laptops/legion-pro-series/legion-p...
Running on a 4070 (laptop) so it's quite possible that first number is meant to be 1371 especially as some others (tests 2/3) hit 500+. Turning GPU off + using crappy APU results in a long test with bad numbers (whereas the 4070 has it finished in under 30 seconds). I'll go try the fixed one...
I just bound window_set_topmost() to a key to switch between states and it works so I just have a timing issue by the look of it.
The end result is that if dual monitor I can select which monitor to use for the app and/or extend it to use both.
The most useful thing about this in dev is having IDE on one screen and app on another
Looking at the Delphi source code fsStayOnTop is slightly different (two more flags in last param)
SetWindowPos(Handle, HWND_STYLE[FFormStyle = fsStayOnTop], 0, 0, 0, 0, SWP_NOMOVE or SWP_NOSIZE or SWP_NOACTIVATE or SWP_NOOWNERZORDER);
HWND_STYLE[FFormStyle = fsStayOnTop] is equal to HWND_TOPMOST if fsStayOnTop otherwise HWND_NOTOPMOST
Just tried it in Delphi
procedure TForm1.FormCreate(Sender: TObject); begin form1.Width := 5120; form1.Height := 1600; form1.Top := 0; form1.Left := 0; form1.FormStyle := fsStayOnTop; form1.BorderStyle := bsNone; end;
Did exactly what I was after (but not in GM...)
I take it topmost is just altering the Z order of the window as opposed to what Delphi's fsStayOnTop does
Possibly I need to get to the TOPMOST option here?
Yeah, I eventually found it - but importing the yymps lists doc html file in included file.
Anyway - after finding window_set_topmost(1); it don't actually do what I was after using something like....
window_set_rectangle(0, 0, 5120, 1600);
window_set_position(0, 0); // These can be negative in some situations
Taskbar still shows - think I'll go try it with a 'proper' language - must be possible as several games non-GM appear to do it without using exclusive full screen
Just grabbed window_command_hook-for-GMS2.3+.yymps import appears to be missing the html documentation
Specifically I just wanna make a 5120x1600 window stay on top when displayed accross two monitors (a 2560x1440 + a 2560x1600) - experimenting with multi-monitor game (but Taskbar is showing on top of window on the smaller monitor - full screen not suitable for multi-monitor). My test "bouncing block" displays under task bar when at that position
Can you dynamically create new tabs? i.e. if I had
group.AddTabs(0, [tab_inv, tab_com, tab_rs]);
then want to create a new tab...
var tab_new = new EmuTab("NewTab");
I can't see how to insert that into the existing list
Shouldn't there be 2 DLLs, a 32 bit default and a 64 bit via a proxy named SpriteAtlas_x64.dll. As it stands loading the yymps and blindly hitting run will error as you won't be on 64 bit runtime by default (you'll be in 32 bit mode - hence the error). See the "What If I Want To Make A 64bit DLL" section in the docs,
DropDown is simple - combine Edit, Button + List
Trees - yeah, far more complex but allow a familiar (Windows Explorer) way to group things. Structs are ideal for defining the tree + could be load from/save to storage.
I suppose Menu would be cool too - Main + context/Pop-up - again, a tree structure...
Flog it all to Yoyo to save them writing their planned own version :)
Temp file storage breaks license terms - particularly as there are undelete utilities.
Surfaces are not a solution here as a 4k x 4k RGBA takes up 67,108,864 bytes and GZ compression won't get that back to PNG sizes (only PNG will do that).
Guess a decode buffer to surface extension is required...
I was just thinking of looking into writing something like this. Is there a way to extract a PNG (or whatever) from a XZip and decode it to a surface (if not I'll still have to look into writing my own version). Basically I want to download an encoded archive with licensed assets and load them into a game - you know, DLC...
I've got as far as downloading assets (un-encrypted) and creating sprites from them but encryption is vital when it comes to keeping to license terms so any assets need decoding - not something I can get GMS2 to do (without writing a PNG extension I guess which seems like re-creating the wheel)
I also got no colour using view3dscene so I investigated by exporting a model from Asset Forge to OBJ. The problem is with the materials definition file(s) *.mtl
An example from your MTL is ...
Ka 0.0000 0.0000 0.0000
Kd 0.5176 0.4196 0.3333
Ks 1.0000 1.0000 1.0000
Tf 0.0000 0.0000 0.0000
While the same material is saved by Asset Forge as ...
Kd 0.5176 0.4196 0.3333
Going thru the OBJ specs I note that the entry of ...
Ks 1.0000 1.0000 1.0000
Is overriding all other colour definitions making everything white. Asset Forge ignores at least the Ks entry so it shows the correct colour
A simple fix is to simply remove all the Ka, Ks, Tf, d and Ns lines from the mtl file (took me a few seconds in notepad++ as all the lines that want removing are identical)
I'd post a fixed mtl file but there's no upload here
Once you have the fixed mtl then view3dscene and other programs will display colour properly - like this...