Getting my game to Steam

Started by Ashmoor, October 16, 2021, 18:36:24

Previous topic - Next topic

Ashmoor

I am trying to get my game to steam. Managed to upload and run it from the client. However, when the steam overlay pops up, something goes wrong and button edges become jagged as if there is no more anti aliasing. Do you have any idea why that happens and/or how to fix it?

My game is built with BMax Vanilla and so far I didn't use any Steam module.

therevills

I havent seen that we my games on Steam... I did have to do a hack for the Steam Overlay where I had to reset the virtual resolution, viewport, origin in the Cls method, it may help you:


Function Cls()
If Game.UsingSteam And (Game.Driver = DIRECTX_DRIVER Or Game.Driver = OPENGL_DRIVER)
If Game.DriverDX11 = 1
brl.max2d.Cls()
Else
Local sw:Int
Local sh:Int
Game.GetResolution(sw, sh)

Local clsr:Int, clsg:Int, clsb:Int
Local r:Int, g:Int, b:Int

GetClsColor (clsr, clsg, clsb)
GetColor (r, g, b)

SetVirtualResolution (GraphicsWidth(), GraphicsHeight())
SetViewport(0, 0, GraphicsWidth(), GraphicsHeight())
SetOrigin(0, 0)
SetClsColor(0, 0, 0)
brl.max2d.Cls()

SetVirtualResolution(Game.virtualWidth, Game.virtualHeight)

SetViewport(Game.vxoff, Game.vyoff, sw, sh)
SetOrigin(Game.vxoff, Game.vyoff)
SetClsColor(clsr, clsg, clsb)
SetColor(r, g, b)
brl.max2d.Cls()
EndIf
Else
brl.max2d.Cls()
EndIf
End Function

Ashmoor

That looks interesting. Thanks!

So you reset the resolution each frame? Did it ever slow down your games?

How do you use DX11 with Vanilla?

I have submitted my game for review. I'll wait for their reply and then will try your approach. It is either a directX issue or something related to the window parameters. Steam overlay may be setting something like a different scaling to my window, leading to this glitch. It does not happen in full screen.

Derron

therevills code should not affect performance much.

SetVirtualResolution (GraphicsWidth(), GraphicsHeight())
-> adjusts some variables and updates the projection matrix (eg d3d9: _d3dDev.SetTransform D3DTS_PROJECTION,matrix)

SetViewport(0, 0, GraphicsWidth(), GraphicsHeight())
-> sets scissor window / rect (am not sure if this would be needed for fullscreen)

SetOrigin(0, 0)
-> adjusts 2 integer variables

SetClsColor(0, 0, 0)
-> adjusts a single integer


so it should be a big performance hit :)


DX11:
https://github.com/davecamp/srs.mod
(if no longer compatible with vanilla - go back in commit history and download an earlier revision)


bye
Ron

Ashmoor

#4
Thanks Derron. I got DX11 Working. There is a version already packed with vanilla, I just didn't know how to use it.

When I try to build the SRS/d3d11graphics.mod module I get an error:


►srs.d3d11graphics was scheduled to next iteration
Build Error: failed to compile M:/programare/BlitzMax Versions/BlitzMax Vanilla With DX11/mod/srs.mod/d3d11graphics.mod/DeviceModeSettings.ccc1.exe: error:
CPU you selected does not support x86-64 instruction set

►►►►srs.d3d11graphics was not built. See error information on latest attempt.


What is it that triggers it to try to build for x64? It does have a specific compiler directive ?win32 and still it throws the error. Is this supposed not to build for x32? The same thing happens if I try to rebuild the version that came with Vanilla instead of the latest version from github.

Edit: I tried to build from console using bmk makemodule -a -g x86 and still get the same error

Derron

Cannot help you there... am not using vanilla anymore. Best bet is to ping "@col" in the discord channel so he becomes aware of your issue and might chime in with a solution/guide.


bye
Ron

Ashmoor

Ok, thanks, I'll pester col in the discord channel :)

col

@Ashmoor
Hiya,

It looks like something is going a little wonky there. Your build system is trying to build

'...DeviceModeSettings.ccc1.exe'

which is completely wrong. Maybe you're building 'DeviceModeSettings' the file as the 'main build file' in the editor?

In the meantime you could try deleting the '...\d3d11graphics.mod\.bmx' folder. Note the \.bmx folder, plus any .a and .i files in the d3d11grahics.mod folder, then rebuild the module and it should be ok.

The \.bmx\, .a and .i are all a part of the build process and will be recreated when rebuilding the module.
https://github.com/davecamp

"When you observe the world through social media, you lose your faith in it."

Ashmoor

@Col, hi :)

I am not setting the build file. I am just pressing build modules. Or using the advanced module builder in BLIde. I tried building it with NG x86 and it worked fine.  I downloaded vanilla 1.50 again from rooster's itch.io and it does not come with the srs.mod  Maybe that module was built with ng and then copied into vanilla. I didn't test it extensively to see if it crashes in vanilla.

I deleted all .a .i and .bmx folder and none of the submodules builds with vanilla now.

Could it be an issue with my minGW and gcc? I have gcc 8.2. I have several versions of minGW and gcc on my drive but I don't know how to switch between them. Changing minGW path in BLIde does not seem to affect the gcc version.  Thanks.


Derron

it might be a GCC / MinGW issue yes.

If you copy the .bmk files and "bmk.exe" from NG over to vanilla, it should work there with "vanilla" (bcc) too. But Bruceys BMK (so the NG version) has the benefit of:
- auto compiling necessary modules (no need to precompile all of them)
- it prefers the MinGW you store in the blitzmax subfolder "MinGWx86" or "MinGW32" (so mypath/to/blitzmax/MinGW32")
- the "lib" folder of vanilla is then obsolete (uses the one from the used MinGW) - prior you needed to copy over the MinGW-files into the lib folder if you used a different MinGW than used when shipping the BlitzMax-Vanilla-Folder
- so an easy way to use a specific minGW version without having to install over an existing one (eg you could have 2 blitzmax folders with individual minGW versions)

As usual: backup your original data first.


bye
Ron

col

Quoteand none of the submodules builds with vanilla now
What are the symptoms here?
    The build module button is greyed out (which would suggest that BMax cannot see your MingW installation)?
    The building of modules starts but it just doesn't build the module(s)? Do you mean all modules? or just the d3d11 (and related) module?

As far as I'm aware D3D11 doesn't come with any installation of 'Max, including not included with 'NG but I stand to be corrected :)

You could do as Derron suggests (copy the files from NG that are related to building in to your vanilla setup) as it makes things more intuitive when using different versions of MingW - You can have multiple installations of 'Max each with their own version of MingW in the Max installation itself to help keep installations clean and tidy.

Other than that then you'll need to modify the Windows environment variables, and copy some lib files from the MingW install into the 'Max/lib folder - This approach can get very messy if you're changing MingW versions. It can be the cause of many many bugs if you get the lib files mixed up with files from the wrong version of MingW. You're much better to use Bruceys approach as Derron suggests.
https://github.com/davecamp

"When you observe the world through social media, you lose your faith in it."

Ashmoor

I copied bmk.exe and *.bmk from NG win32_x86_0.120.3.41 to vanilla/bin, copied MinGW from the same NG version to Vanilla but it has the name "MinGW32x86". It still does not work. There are plenty of errors, missing files, conflicting types etc.

At this point I think I'll just be better off switching to NG and sticking with it.

<<What are the symptoms here?>>

The building of modules starts and works up to srs.mod which contains d3d11graphics.mod, d3d11max2d.mod and directx11.mod. None of the srs submodules builds now because I deleted the .a .i and .bmx in all of them and they depend on one another.

<<You could do as Derron suggests (copy the files from NG that are related to building in to your vanilla setup) as it makes things more intuitive when using different versions of MingW - You can have multiple installations of 'Max each with their own version of MingW in the Max installation itself to help keep installations clean and tidy.>>

Yes, I do have a few install setups and BLIde keeps them tidy. I would use Derron's method if it wouldn't throw all the errors it does at the moment.

As I currently have the module build by NG and apparently it works in Vanilla I'll give up the pursuit of actually building it in Vanilla. I'll run some tests to make sure it does not Crash the game but the main take away from all this is that I must switch to NG as soon as possible.

Thanks for all the help!




Derron

I booted up an old MicroXP VM ... in there was already a "BlitzMax.150" folder - and a MinGW32 folder within it (it contained a TDM MinGW GCC 4.5/4.6 Series).
It of course also contained a newer bmk.exe + bmk files (from 2019 though)

srs.mod was in there too (maybe you were using my blitzMax.7z archive :)) and it compiled fine.


So ... I checked if no MinGW was in path or so ... and installed it again ... and this time used a newer MinGW (from NG 0.129) and there I got some compilation issues with basic modules. So ... it might be that newer MinGW need adjustmends in vanilla modules.


bye
Ron

Ashmoor

<<srs.mod was in there too (maybe you were using my blitzMax.7z archive :)) and it compiled fine.>>

Did you upload it anywhere publicly? I don't remember adding the srs module to my install. Maybe I got it from you or someone else a few years back when syntax bomb just opened.

I'll give it one more try with an older minGW, when I get a little bit of time.