Win11Arm - Socoder

-=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- (c) WidthPadding Industries 1987 0\|40\|0 -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=-
Socoder -> Hardware and Technology -> Win11Arm
Tue, 28 Nov 2023, 04:34
Jayenkai	Win11Arm Thought I oughta make a thread for this, because (entirely my own fault) it's ending up in everyone's showcases. Apologies to all. In the recent post, Kuron suggested it might just be DirectX not working well in UTM, and as true as it is that UTM doesn't "do" accelerated graphics driver stuff, it's not as clear cut as it seems. FR-025 is (apparently) a DX9 engine, and that runs flawlessly in UTM/Win11Arm, and if I run most things from within Blitz3d or Max, they also seem to run ok. I really do need to narrow down what's causing these issues, and also whether they happen on "real" Win11Arm, as opposed to just a virtual one running on a Mac. If anyone can think of a quick and cheap Win11Arm test device for these things, let me know! -=-=- ''Load, Next List!''
Tue, 28 Nov 2023, 04:45
Kuron	Problem with a Win11 ARM device, wouldn't you need one with an ARM processor capable of x86/x64 virtualization? Going from memory of the first Windows ARM versions that were released. I am amazed that what I sent you ran on an ARM version of Windows, as it wasn't ARM or UWP.
Tue, 28 Nov 2023, 04:54
Jayenkai	Exactly the reason we need to test these things. I'm pretty sure "gamers" aren't going to be switching to ARM any time soon, but if people who buy smaller systems "for remote working", etc, end up switching to ARM devices in the future, I do think we need to check things run ok on them. Otherwise we'll have to start doing that thing where we say "Windows 95+ but not ARM unless it has true x86 compatibility" in all the descriptions! Bah, humbug!! -=-=- ''Load, Next List!''
Tue, 28 Nov 2023, 05:17
Kuron	Only ARM I have is my Chromebook. The two Windows 10 tablets I bought are Intels, the models before mine, and after were ARMs. I am happy that the example I provided ran fine. However, I am considering using SDL2 or Pygame, Love2D, LibGDX, BBC BASIC for SDL 2.0, BlitzMax or Blitz+. So, the 9+ year old example running fine is not too helpful since I may not be going that route. That said, I have never expected anything to run on ARM versions of Windows. Anything that does is gravy, IMHO.
Wed, 29 Nov 2023, 21:00
Eikon	I know you've had some issues running my recent games that use the GLMax2D graphics driver. BlitzMax [ng] docs mention that it supports four graphics drivers GLGraphics, GLMax2D, D3D7, and D3D9, but I could only get GLMax2D and D3D9 to work on my Windows 10 system. I haven't been able to test native Windows 11 as my system doesn't have support for it but I assume it works OK. I made a test that runs Max2D and D3D9, would be interested to see if either of them work for you on ARM https://www.eiksoft.com/Win11ARM.zip
Thu, 30 Nov 2023, 01:29
Jayenkai	Oooh, now.. That IS interesting.. Both "work", but the Max2D doesn't work "right", and I presume that's going to be the crux of it. Both run perfectly fine in CrossOver, so again, is that UTM being shit or is it Win11Arm doing it..? I just don't know. -=-=- ''Load, Next List!''
Thu, 30 Nov 2023, 13:34
Jayenkai	It's the font. It's the fucking font..* And I went back and forth on this for a bit, but your game doesn't actually use a standard .ttf font, only a bitmap font. OpenGL in Win11Arm must be fudging the default font loading, somehow, and it's screwing everything else over as a result. Stick a .ttf font in the game dir, and add the line font=LoadImageFont("font.ttf",8,SMOOTHFONT);SetImageFont font --v EVEN IF YOU NEVER USE IT... Acknowledge font is a common blocky retro font. This will 100% fix the test above, so it may very likely work in your game, too. I can't test if it works for your games, since I can't get them to compile. (They crap out at the includes!) But if it works like it does in the test, I'm pretty damn sure that's what's causing it. Somehow. How bizarre.. * Note :This may not be 100% accurate, but it's all I could find, and it certainly seems to be the issue from what I can see. -=-=- ''Load, Next List!''
Thu, 30 Nov 2023, 13:39
Kuron	Good job of tracking down the issue.
Thu, 30 Nov 2023, 20:49
Eikon	That is wild, never would've figured the font loading would affect all that. I've recompiled a Joust X EXE using your fix to test, just overwrite after unzipping v1.2 https://www.eiksoft.com/wsc93151839/joustx/joustx.php Fix https://www.eiksoft.com/joustx_arm.zip * Edit: Reuploaded, had to Import BRL.FreeTypeFont for it to work right If the fix doesn't work here, my thinking is that it would be because of the Framework/Import statements I'm using in my games to only take what I need, whereas the examples were including every module that is a default. It's likely the game is missing some other module that it needs to work properly
Thu, 30 Nov 2023, 20:57
Kuron	Never cease to be amazed at what little thing may set off emulation incompatibilities. but I could only get GLMax2D and D3D9 to work on my Windows 10 system. I would not recommend doing it, but it is possible that DX7 runtimes would need to be installed. IIRC, this was the way it was with Windows 7. It supported 9 out of the box, but 9 was not backwards compatible and you had to also install DX7 runtimes. No idea how it is now with Windows 10, as 9 years not being involved in this stuff, I didn't keep up too well.
Fri, 01 Dec 2023, 02:07
Jayenkai	Nope, try again The fixed version is still failing quite a bit because you renamed the font! Blitz has always had a "Don't rename the fonts" rule, as far back as I can remember. The font's filename should have the exact name as is shown in the "Font name" dialogue when you double click the font. In this case, the font name should be "Acknowledge TT (BRK).ttf" However, do note in that first picture, it's all gone awry, but is definitely just showing the letter B over and over and over and over. I'm still pretty sure this is the font-loader breaking. Have another go Try Edit Undo.ttf Less brackets in the name to fudge things up It's called "Edit Undo", you can name it "Edit Undo.ttf", and it should work just fine. (And maybe do a quick test to see if it does indeed load+output fine. That should be visible on your own system. Errors loading fonts are quite noticeable.) -=-=- ''Load, Next List!''
Fri, 01 Dec 2023, 07:45
Eikon	That's strange, I did confirm that the font was working in program after renaming it, but I do remember the font renaming issue from way back now. Let's see how the edit undo font does https://www.eiksoft.com/JoustX_editundo.zip
Fri, 01 Dec 2023, 09:17
Jayenkai	Damnit.. No luck. Still all B's on the screen. It's taking ages to load, too, so I imagine there's something else going on. Bah, humbug. This is very frustrating. I'll keep digging and let you know what else I can find. Sorry for all the tweaking you've had to do so far -=-=- ''Load, Next List!''
Fri, 01 Dec 2023, 13:11
Kuron	Makes a mental note to prerender all text as actual images to avoid this issue in anything using OpenGL. No fonts or no bitmap fonts.
Fri, 01 Dec 2023, 13:43
Jayenkai	Aah, but, no, but yeah... It's very confusing. But Eikon is pre-rendering his font. ... so.....?! My old 2010/11 framework seems to be running without a hitch, so either it's something Eikon's included, or it's something I've included that's bypassing the issue. I'm still trying to track it down. I'm still struggling to compile Eikon's code, though, so .. whatever it is that's stopping me, there, is possibly the culprit, maybe? Unsure. -=-=- ''Load, Next List!''
Fri, 01 Dec 2023, 14:14
Kuron	No, not what I am talking about. He is prerendering them at runtime. I am talking about doing it at design time (when you design all the other artwork) and save each piece of text (or screen of text) as a BMP. Then you are simply dealing with images at runtime. 24 bit BMPs compress really well for distribution. Often the best way to do it, even if not under emulation, as otherwise you lose a lot of FPS dealing with text in any form. OpenGL & DirectX APIs are designed for images. And due to variances in cards and graphics chips and their driver versions, what may work on one system won't work well on another. Adding emulation into the mix causes a whole other potential for issues.
Fri, 01 Dec 2023, 15:15
Jayenkai	Nah, you can easily blast 1000 small sprites onscreen. 100 of those being font images won't make a dent. But if you render them to larger rectangular sprites, can you then keep up the speed of having such large sprites being drawn amongst the smaller ones? I expect likely not, and the change between different sized sprites will likely be more extreme than just drawing the characters. -=-=- ''Load, Next List!''
Fri, 01 Dec 2023, 15:26
Kuron	I would be using batch rendering... Of course that would be with my own OpenGL engine. With Blitz, you are limited to what is provided. IMHO, although the GL in Max supported some fancy effects, it was quirky and had some compatibility issues, the GL in B+ was significantly faster and far more compatible. shrugs horses for courses. Keep in mind Eikon's stuff runs fine on the intended platform and it runs fine under Wine (which Crossover uses). Just choking under UTM. My guess would be the x86 emulation 11ARM is doing, since BRL products would choke on certain Windows setups and graphics card drivers. If there wasn't that history of incompatibilities with the 3D side of BRL products, I would say it was UTM.
Sun, 03 Dec 2023, 14:42
Jayenkai	Curiouser and curiouser... -=-=- ''Load, Next List!''
Sun, 03 Dec 2023, 17:25
Kuron	Hmm...
Thu, 04 Jan 2024, 10:28
Jayenkai	From this thread ricardo_sdl Hi! Apparently UTM can't handle games very well yet, from their website: "Can I run games? No, probably not. UTM does not currently support GPU emulation/virtualization on Windows and therefore lacks support for 3D acceleration (e.g. OpenGL and DirectX). You may be able to run older games with software rendering options, but nothing with hardware acceleration. There is experimental support for hardware OpenGL acceleration on Linux through Virgl." Whilst I 100% appreciate that, and agree that UTM just isn't up to doing anything wonderfully graphical, the reason that this particular issue is doing my head in is ... My games, for whatever the heck reason, will run absolutely flawlessly when compiled using the exact same version of BlitzMax that I've tried compiling Eikon's games with. .. But Eikon's games do the weird-ass image rendering breaking thing.. Still haven't worked this out. (* Note : My games will run fine whether using OpenGL, DX7 or DX9. Though DX7 is slow as molasses.) -=-=- ''Load, Next List!''
Thu, 04 Jan 2024, 20:48
Eikon	I bet if you put Framework BRL.GLMax2D or Framework BRL.D3D9Max2D at the top depending, and maybe Import a module or two, you might see the same font issues. That's the only thing different I'm doing that I can think of. When it's including everything it's picking up whatever is fixing the bug. Maybe I need to Import something related to fonts
Fri, 05 Jan 2024, 01:35
Jayenkai	Aaah, there we go. Yeah. So, what makes standard OpenGL mode different to BRL.GLMax2D mode? Is one using a different version of OpenGL than the other? OpenGL tests suggest the "gfx card" is 1.0 only, so nothing 2 or above is supported. That's likely the reason. So then we're back to "Just UTM, or Win11Arm's compatibility layer?" Should be noted however, that adding "Framework BRL.D3D9Max2D" also breaks .. something..? Everything acts like it's ok, but the graphics aren't always scaling the way they're supposed to. This could be a related issue. The quirks continue!!! -=-=- ''Load, Next List!''