sm64pc / sm64ex

Fork of https://github.com/sm64-port/sm64-port with additional features.
1.55k stars 475 forks source link

(Question) Will older operating systems become supported? #214

Open Damian9303 opened 4 years ago

Damian9303 commented 4 years ago

For a game released in 1996, I'd expect operating systems older than Windows Vista (2007, est. 9 years) to be able to run this executable. But in doing so, it complains about a dependency named GetTickCount64 missing from KERNEL32.DLL. Of course with Windows XP (and possibly Windows 2000 w/ blackwingcat's Extended Kernel), you can as I found out use a program named vista2xp to make it dependent on it's own DLLs to allow play. Although, like I said it turns it from one executable to like one executable and a few of those DLLs. What I'm just wondering is if there are plans to allow support for these systems through OpenGL (and possibly any DirectX of choice (8-11)), maybe even SDL1.2 support for the lowest of the low (w/o KernelEx or something similar) just like the image with it running on Windows 98?

rawr51919 commented 4 years ago

OpenGL is the best bet for something like this. 1.2 support is on the todo list. Besides, QIndieGL's there if you can only run D3D stuff anyways

Damian9303 commented 4 years ago

OpenGL is the best bet for something like this. 1.2 support is on the todo list. Besides, QIndieGL's there if you can only run D3D stuff anyways

Alright, neat. I'd rather not go through emulators, as it'd probably slow it down on shit computers since not optimized and all that. The DirectX comment was only hypothetical because of the DX12 compile this project was first surfaced as, and it's likely better off not needed if not being dealt with. So it's unlikely that I will. But yeah, thanks.

fgsfdsfgs commented 4 years ago

This is because SDL2 only supports XP and higher. Should run on XP though. It is completely possible to write controller and WM modules for SDL1.2, but the game will still require at least GL2.1. It is possible to write a GL1 backend, but probably a big pain in the ass.

Damian9303 commented 4 years ago

This is because SDL2 only supports XP and higher. Should run on XP though. It is completely possible to write controller and WM modules for SDL1.2, but the game will still require at least GL2.1. It is possible to write a GL1 backend, but probably a big pain in the ass.

And in this case it doesn't, unless it becomes finetoned with dependencies for Vista+ functions omitted. Windows 9x support is a stretch thinking about it (although SDL1.2 as said is on the to-do list so something may come out who knows), but at least Windows 2000 (w/ blackwingcat's Extended Kernel)/XP support should be easier to manage. If no one got anything to test, I can do so if need be.

enigma9o7 commented 4 years ago

I have an old (10 years newer than this game) linux machine with sdl2, but only gl1.3, so a gl1 backend would allow it to build. Re PITA, sounds like unless a developer is in a similar position to me, probably won't happen anytime soon. Will have to live with retroarch with gl1.

fgsfdsfgs commented 4 years ago

Are you building a 64-bit executable? The game doesn't call GetTickCount64 manually anywhere, so might be either SDL2 or the MinGW libc (the game does call clock_gettime(CLOCK_MONOTONIC) which might not be supported under XP for whatever reason).

UPD: It appears to be linked to this issue:

developers of winpthread and other runtime libraries bumped the minimum supported OS version to Windows 7 time ago because they want to take advantage of new APIs. This is not going to change. And MSYS2/Cygwin do not support Windows XP any more.

So you need to use an older version of MSYS2/MinGW or an older version of some runtime libraries (there are solutions in that issue thread). PR #93 recently fixed compilation on older toolchains, so it should work with anything starting at around GCC5.

yksoft1 commented 4 years ago

I tried this code on a notebook with 1st-gen Intel i5 processor with its 1st-gen HD graphics, which claims that it had OpenGL 2.1 support, but it failed to run. I suspect this OpenGL port, in fact, needs OpenGL 3.0 or higher.

enigma9o7 commented 4 years ago

https://github.com/sm64pc/sm64pc/commit/c540712154e6825e189f586b67117388b2006052

Looks like gl1 was just committed to nightly. Thanks. I hope bum is okay :)

rawr51919 commented 4 years ago

@yksoft1 an OpenGL 1.3 renderer just came out a few commits ago on nightly. Perhaps try that out on an older system and see how that goes.

superbonaci commented 4 years ago

The gold version for games was Windows 98 SE, which is the last one that can boot to MSDOS directly.

yksoft1 commented 4 years ago

@yksoft1 an OpenGL 1.3 renderer just came out a few commits ago on nightly. Perhaps try that out on an older system and see how that goes.

Tried that and it worked on a 1st-gen Core i3 system, under Windows XP. Clipboard02

superbonaci commented 4 years ago

Windows XP is a reasonably new operating system. A proper test would be to compile and run it on Windows 98 Second Edition.

rawr51919 commented 4 years ago

I'd say go for broke and compile it on Windows 95 OSR2.5. I think OSR2 was from around the release year of the game iirc

fgsfdsfgs commented 4 years ago

Need optional SDL1 based backends for that. Or something else entirely.

rawr51919 commented 4 years ago

Win98 First Edition might be able to run this too. Would be worth a test

yksoft1 commented 4 years ago

It more or less worked on an Atom N270 netbook, but with many graphic glitches. Clipboard01 Clipboard04

fgsfdsfgs commented 4 years ago

Can you try getting a log out of it and posting the GL extensions/version part here? Might work if you run it from cmd like this sm64.exe > log.log. Or just build it with WINDOWS_CONSOLE=1.

yksoft1 commented 4 years ago

Can you try getting a log out of it and posting the GL extensions/version part here? Might work if you run it from cmd like this sm64.exe > log.log. Or just build it with WINDOWS_CONSOLE=1.

Here it is:

GL extension detected: GL_ARB_multitexture
GL extension detected: GL_ARB_texture_env_combine
GL_VERSION = 1.4.0 - Build 7.14.10.4926
GL_EXTENSIONS =
GL_ARB_depth_texture GL_ARB_fragment_program GL_ARB_multitexture GL_ARB_point_parameters GL_ARB_shadow GL_ARB_texture_border_clamp GL_ARB_texture_compression GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_dot3 GL_ARB_texture_env_crossbar GL_ARB_transpose_matrix GL_ARB_vertex_buffer_object GL_ARB_vertex_program GL_ARB_window_pos GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_func_separate GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_clip_volume_hint GL_EXT_compiled_vertex_array GL_EXT_cull_vertex GL_EXT_draw_range_elements GL_EXT_fog_coord GL_EXT_multi_draw_arrays GL_EXT_packed_pixels GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_specular_color GL_EXT_shadow_funcs GL_EXT_stencil_two_side GL_EXT_stencil_wrap GL_EXT_texture_compression_s3tc GL_EXT_texture_env_add GL_EXT_texture_env_combine GL_EXT_texture_lod_bias GL_EXT_texture_filter_anisotropic GL_EXT_texture3D GL_3DFX_texture_compression_FXT1 GL_IBM_texture_mirrored_repeat GL_NV_blend_square GL_NV_texgen_reflection GL_SGIS_generate_mipmap GL_SGIS_texture_edge_clamp GL_SGIS_texture_lod GL_WIN_swap_hint 
GL_EXT_fog_coord available, using that for fog

I think the problem could be the GMA950 driver instead of our backend, since Intel's Windows graphics driver had rather bad compatibility record in that age.

fgsfdsfgs commented 4 years ago

I didn't really expect it to work correctly on an Intel GMA chip anyway. Might need a config flag to disable GL_EXT_fog_coord usage, maybe it's not properly implemented on GMA. Either that or the blend mode isn't resetting properly.

enigma9o7 commented 4 years ago

I finally tried it on Pentium 4 w /GL1.3. First make it complained about GLSL ES 1.00 not supported, then I remade with LEGACY_GL=1 and seems to work very well. (in full screen 640x480 very playable) shot-2020-05-23_13-15-39

that was under 32-bit ubuntu 18 with linux 4.9. So I tried the binary on an older OS, slitaz 5 with linux 3.16. It complained about glibc 2.17 (slitaz only has 2.14). Tried to make, but it complained, probably also related to glibc version, as I used gcc 8.3 image

fgsfdsfgs commented 4 years ago

Add a -std=gnu99 to the CFLAGS in the Makefile.

rawr51919 commented 4 years ago

@enigma9o7 it's TEXTURE_FIX=1 not TEXTUREFIX=1 btw -std=c99 would also help with your compilation issue

enigma9o7 commented 4 years ago

Thanks for catching that texture_fix @coltongit

I tried with -std=c99 http://paste.slitaz.org/?5f29b9eb6a2edd7e#dF0S6PyEvEf9xKx1IJ95R4MaqKdF7aWjlgY8FIPVrjg= and no complaints about c99

I tried with -std=gnu99 and seems to go farther http://paste.slitaz.org/?0d7ffcef4e10bc2f#hcgjoRRBfcko8oguKOw382a+dZQXLMtkjpQeh61oj+4= yet it complains about c99

I haven't previously edited a Makefile, I just put "CFLAGS += -std=c99" for example on the line before it checks for puppycam option... assume that should work...

fgsfdsfgs commented 4 years ago

That's probably too early. Find the other CFLAGS definition for your OS and add it there, or after that block.

enigma9o7 commented 4 years ago

Yeah that's exactly where I put it. Right after CFLAGS for linux block, next thing is checking puppycam, I put it in between those, outside any ifs. (I also tried the same command inside the linux block, same difference).

fgsfdsfgs commented 4 years ago

That's interesting. The flag is in the command line.

enigma9o7 commented 4 years ago

I bet it's related to glibc 2.14. I've ran into this in the past with slitaz trying to run binaries or build recent stuff.

Anyways consider this a non-issue. We've see proof/screenshots that it works on XP, I've personally confirmed it works great on 32-bit ubuntu (on 15-year-old single-core 512Mb pc with gl 1.3), that's old enuff OS, this works on old OS just fine now that gl1 works. Nobody needs to run this on win9x (imo).

What do you think @damian9303 good enuff to close?

floppyD commented 4 years ago
OpenGL 1.2+ is required. Reported version: 1.1

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

Any plans for older OpenGL versions? lol

fgsfdsfgs commented 4 years ago

It's probably possible with multipass rendering, but I don't think I'll be the one to do it. At least not in the nearest future.

fgsfdsfgs commented 4 years ago

Actually for shits and giggles you could go into src/pc/gfx/gfx_opengl_legacy.c and change line 519 to if (vmajor < 2 && vminor < 1 && !is_es) { and see what happens.

floppyD commented 4 years ago

Got this:

GL extension not supported: GL_ARB_multitexture
fgsfdsfgs commented 4 years ago

Oh well.

enigma9o7 commented 3 years ago

I'm bumping this old thread cuz now it truly is answered. With SDL1 and GL1.1, it'll run on Win98 even!

https://cdn.discordapp.com/attachments/721805292920373371/749465960955641866/Windows_98_Second_Edition-2020-08-30T03-06-25-860639000Z.webm

enigma9o7 commented 3 years ago

shot-2020-08-30_12-03-04

yksoft1 commented 3 years ago

I'm bumping this old thread cuz now it truly is answered. With SDL1 and GL1.1, it'll run on Win98 even!

https://cdn.discordapp.com/attachments/721805292920373371/749465960955641866/Windows_98_Second_Edition-2020-08-30T03-06-25-860639000Z.webm

I'm wondering what graphic cards with Win9x drivers could run sm64pc accelerated. I assume that it needs at least Geforce 2 level.

superbonaci commented 3 years ago

@enigma9o7 great test.