while not compeletely needed, we use the stencil buffer for some stuff, so dont really feel like having to deal with potential issues here
besides, probably any gpu in almost the last 2 decades should support this and even gl3.0 anyways, so this is just bloat we do not need
dont do locale stuff from thread, use localtime_r && localtime_r as localtime is not threadsafe either
G_GetDemoDate returns malloc´d buffer again, tho not strictly necessary
also, fix dates not always being initialized in all cases and type issue with G_GetCreationTime
not sure why there werent any, the other map lumps have those, and a corrupted file may have those missing also which would just crash instead of telling you wtf is wrong
this whole sky handling is just incredibly stupid and wouldve been such an easy fix, but here we go
this is just more stupid hacks but i really dont feel bad here since the code already hacked around a bunch of shit
just hoping this wont cause any issues on some maps and needs testing
sigh
It was probably caused by menupath being modified when replay load
thread is in the middle of checking it, now the check for "valid"
replay load thread is simpler. Also as comment says, there still are
few reported data races for replaynamesloaded but i THINK it should be
fine, since the only "data race" that could be harmful here is
replaynamesloaded switching from true to false, which would mean
demolist_all is suddenly invalidated, and that shouldn't be possible
because we only switch replaynamesloaded from true to false inside main
thread while also locking the "search mutex"
(this is so wordy lol)
matches software now
even if most custom maps were made with opengl in mind, stuff did not work anyways for years so this shouldnt hopefully cause any issues
matches software now
even if most custom maps were made with opengl in mind, stuff did not work anyways for years so this shouldnt hopefully cause any issues
it should check its own "master" sector for remap behavior NOT the sector it resides in
note: i did not change the ceiling/floor behavior here as i noticed there might be more issues than this with fofs
it should check its own "master" sector for remap behavior NOT the sector it resides in
note: i did not change the ceiling/floor behavior here as i noticed there might be more issues than this with fofs
if smth sets nomd2s those werent set up correctly and enabling models just ended up drawing nothing instead
ideally nomd2s == false should just completely disable the model system but im too lazy for that currently
last remaining static buffer for localskins
now we can remove the limit completely
there are still some static arrays for normal skins remaining, removing those will take a bit more work im currently waaaaay too lazy for
W_CheckFileContains returns -1 if file was not found which still triggered those conditions
so just handle if file was not found to skip doing other stuff in those cases
W_CheckFileContains returns -1 if file was not found which still triggered those conditions
so just handle if file was not found to skip doing other stuff in those cases
i hope and pray this does not explode
localskin lookup per skinnumber straight up did not work and also technically could cause issues if someone would load localskins before other skins
and generally localskins are now ONLY exposed if luaimmersion is enabled
based on https://gitlab.com/kart-krew-dev/ring-racers/-/commit/255570cfca8ac6a2700098036085a48a10a3a84b
this also extends to localskins and some other things that were static arrays before, like the faceprefixes and md2 models
those are now part of the skin_t structs aswell
TODO: dynamic allocate the translationtablecaches so we can completely remove the localskin limits and maybe further cleanup localskin handling
also cleans up a few parts of the localskin handling
and might reduce general memory usage slightly in some cases
this gave me an intense headache ngl
as we use the pool allocator we may check if a mobj points into the address range of the level pool specific to mobj allocations (g_level_large_pool)
this may help in debugging stuff without the need to run things like ASAN or valgrind
read the sectornode list stuff
this means we reuse old stale data in some cases, which also causes strange bugs with orbiting items in some cases, but thats what vanilla does and we HAVE to keep vanilla compat after all
i really hope this does not cause any fun impossible to debug crashes, but what can you do
I was thinking to myself about how 2.1 and before did thinkers and how 2.2 made it into thinker lists and thought "wait isn't memory allocated similar to that?" and well here we are.
this appears to mess up remapping behavior in certain cases (ex. sneaker/spring panels)
since i cba looking into properly fixing this, ill just disable this for now
this appears to mess up remapping behavior in certain cases (ex. sneaker/spring panels)
since i cba looking into properly fixing this, ill just disable this for now
have a distinct name for that build "Phobos", as a nod to Doom
also invert the flag, as it should make adding stuff less headachey
will make this a compiler flag later but too lazy atm
I was thinking to myself about how 2.1 and before did thinkers and how 2.2 made it into thinker lists and thought "wait isn't memory allocated similar to that?" and well here we are.
can just be enabled per MAXPLAYERS define in doomdef
this will also auto undefine COMPAT_VANILLA
no support for tab rankings or intermission rankings at all yet
will port those over eventually from saturn 32p or blankart and clean stuff up
please note this may have bugs since not everything is ported over yet
can just be enabled per MAXPLAYERS define in doomdef
this will also auto undefine COMPAT_VANILLA
no support for tab rankings or intermission rankings at all yet
will port those over eventually from saturn 32p or blankart and clean stuff up
prob did that while sleep deprived, P_WeaponOrPanel includes a few more things than intended to be there
doubt we even use any of those, but i dont want to cause any potential issues agaion
dont think this would cause any issues at all, but i dont feel like maybe causing some dumbass edge cases anywhere really
can test this further after v10 release since its already taking ages
dont think this would cause any issues at all, but i dont feel like maybe causing some dumbass edge cases anywhere really
can test this further after v10 release since its already taking ages
this omits alot of hooks in the profiler, tho not sure if anyone should even care about those back in the list
maybe just have it have multiple pages like perfstats, or better just integrate it into perfstats......
this omits alot of hooks in the profiler, tho not sure if anyone should even care about those back in the list
maybe just have it have multiple pages like perfstats, or better just integrate it into perfstats......
i dont want another stinky library
this would just be an arsepain to include in windoze builds
TODO: make this drawer less of a mess, maybe integrate into perfstats instead?
i dont want another stinky library
this would just be an arsepain to include in windoze builds
TODO: make this drawer less of a mess, maybe integrate into perfstats instead?
-split emeraldhunt handling into its own function
-merge hoop spawn loop into the main mapthing spawnloop
-continue early for things like rings and coins
- reduce the amount of R_PointInSubsector on maps with nights hoops
hopefully reduces levelload time slightly
-split emeraldhunt handling into its own function
-merge hoop spawn loop into the main mapthing spawnloop
-continue early for things like rings and coins
- reduce the amount of R_PointInSubsector on maps with nights hoops
hopefully reduces levelload time slightly
this "works" with a skinlimit of 255
but would cause hard to debug crashes with raised skinlimits and was generally really unsafe and could cause soundnames to not be null terminated aswell as buffer overflows from blind strcpy
the sprintf fix is from Indev originally for neptune
NOTE: if the skinlimit is ever raised above 1024 then freeslotnames NEEDS to be atleast one byte bigger to not truncuate stuff
NOTE2: pretty sure localskins are fucked if any are loaded in servers with 255 skins loaded, but i dont care atm
this "works" with a skinlimit of 255
but would cause hard to debug crashes with raised skinlimits and was generally really unsafe and could cause soundnames to not be null terminated aswell as buffer overflows from blind strcpy
the sprintf fix is from Indev originally for neptune
NOTE: if the skinlimit is ever raised above 1024 then freeslotnames NEEDS to be atleast one byte bigger to not truncuate stuff
NOTE2: pretty sure localskins are fucked if any are loaded in servers with 255 skins loaded, but i dont care atm
didnt feel like cherry picking this since we have most of this already - https://git.do.srb2.org/STJr/SRB2/-/commit/5f8671b1002eea61c1e7e00a9b91f30d732ce261
this means sound test wont have a gaziliion thok sounds anymore, aswell as S_AddSoundFx doesent have to iterate through a huuuuuge list of sounds each time a sound is getting added (if not a skinsound) which might speed up addon load a bit
when using localskins and going over the skinlimit
this should use numskins not numallskins there
no i dont feel like supporting localskins here the other skin commands also dont care
when using localskins and going over the skinlimit
this should use numskins not numallskins there
no i dont feel like supporting localskins here the other skin commands also dont care
not sure if that can happen by itself (nametonum stupidly clamps this to maxplayer range), but a malicious client definitely could cause a buffer overflow there
this much much more closely resembles the software effect
i manually tweaked this until it looked very similar
its still not quite perfect probably, but in many cases its a close match
split it into its own pass
we will draw "refraction planes" before drawing anything translucent
this way we wont cause any draw order issues or anything like that
this is also a bit faster and more sane than the other approach
only caveat: translucent stuff behind water planes is unaffected by refraction
but better than it was before, and sure better than trying to copy the screen per plane or shit like that lol
like this, this should be mostly feasible to actually use, the skybox water stuff kinda was a non issue since i noticed even just normal water does not draw over the map geometry (must have misremembered that part since software does do that), but still might be worth looking into at some point
this sucks
but the final screen texture with the palette render postprocess step will not be in the downsample fbo
so we have to redraw it there with the postprocess step......
this is still better than drawing another screen texture when using paletterender which costs perf
this sucks
but the final screen texture with the palette render postprocess step will not be in the downsample fbo
so we have to redraw it there with the postprocess step......
this is still better than drawing another screen texture when using paletterender which costs perf
tries to replicate the effect from software renderer
this is quite a mess, but finally feel like pushing this since i finally figured out the depth testing stuff
this still has some issues:
-map geometry in front of skybox water will just draw over it completely (not super sure how to fix this other than deferring water rendering after rendering both skybox and normal scene)
-translucent geometry is not included in refraction (and may draw in front of it?), software also suffers from this in certain cases, i just hope its not that visible
this really needs a cleanup at some point
and due to how this is setup for floor and ceiling planes this also costs quite a lot of gpu time (atleast on the cpu side this costs barely anything)
still horrid, but atleast this wont give me braindamage each time i have to look at it
this also read stale data from the previous frames and was just insanely messy
this still sucks ass but oh well
still horrid, but atleast this wont give me braindamage each time i have to look at it
this also read stale data from the previous frames and was just insanely messy
this still sucks ass but oh well
this basically brings it to the latest state from Doom-Legacy before the big refactor (which i had previously ported and tested as well) + some extra stuff from it
sadly this does not seem to fix plane holes, but its a bit cleaner and more accurate in some places
while the big refactor did fix issues with plane holes, it also introduced a few new issues, like z-fighting sneaker panels and significantly longer loading times
may as well just wait at this point for what (or rather if) RR will be doing
this basically brings it to the latest state from Doom-Legacy before the big refactor (which i had previously ported and tested as well)
sadly this does not seem to fix plane holes, but its a bit cleaner and more accurate in some places
while the big refactor did fix issues with plane holes, it also introduced a few new issues, like z-fighting sneaker panels and significantly longer loading times
may as well just wait at this point for what (or rather if) RR will be doing
causes some zfight issues and longer load times
i will look into another solution sometime to try and plug the plane holes
maybe can reuse some parts of this in the original implementation
most of those were added cause they´re cool to look at, but without much thought about potentially giving players that enable such features an "unfair" advantage over others.
- eggboxes wont be rotated while stationary and on the ground anymore (they are meant to deceive players, being rotated makes them stand out alot!)
- players that are about to explode due to eggboxes wont spawn extra red speedlines anymore
- option to show driftlevel per speedlines has been removed
most of those were added cause they´re cool to look at, but without much thought about potentially giving players that enable such features an "unfair" advantage over others.
- eggboxes wont be rotated while stationary and on the ground anymore (they are meant to deceive players, being rotated makes them stand out alot!)
- players that are about to explode due to eggboxes wont spawn extra red speedlines anymore
- option to show driftlevel per speedlines has been removed
dont need all those yaw vars, since they effectively map to gl_viewsin and -gl_viewcos respectively
while those are less accurate due to being fixed point, there appears to be no visual issues from this and seems to even slightly improve performance in some cases
move stuff into a helper func, which just returns if mo != NULL in vanilla compat mode, otherwise returns P_MobjWasRemoved
reasoning for this crap is in the comment above said helper
move stuff into a helper func, which just returns if mo != NULL in vanilla compat mode, otherwise returns P_MobjWasRemoved
reasoning for this crap is in the comment above said helper
dont need all those yaw vars, since they effectively map to gl_viewsin and -gl_viewcos respectively
while those are less accurate due to being fixed point, there appears to be no visual issues from this and seems to even slightly improve performance in some cases
very scuffed up since we dont have the srb2::Draw lib
so it may display stuff out of screen bounds
i also rather not use fmt here but va since i dont want another dependency
needs to be fixed up sometime
- Add lua_profile cheat: calculate average time spent in
hooks over a period
- Show hook times in a sorted table, along with lump name,
script line number and hook type
- Show cumulative time spent in game logic hooks and
percentage of overhead to game logic
stuff added per -file or whatever
this incorrectly rechecked the iwads again instead of the pwads themselves, which let to the game flagging vanilla maps as replaced, setting the game to be modified
stuff added per -file or whatever
this incorrectly rechecked the iwads again instead of the pwads themselves, which let to the game flagging vanilla maps as replaced, setting the game to be modified
pretty sure none of those cause issues currently, but rather not risk stuff as that condition might change from smth else in those cases
its not an expensive call anyways really
pretty sure none of those cause issues currently, but rather not risk stuff as that condition might change from smth else in those cases
its not an expensive call anyways really
needs to be seperate lump
ive just hardcoded sounds we´ve found for now
this whole thing sucks, but idk how else to detect things
ideally would just move intro sounds to the sound system entirely instead of relying on the stupid play sfx line special, but oh well cant do anything about it now
before this flagged every file with lumps that contained the MAP as string somewhere, like palettes and such
this is kinda messy but i really do not want to dupe this huge block of code, neither do i want to convert this to ceepeepee again to mess about with templates
oh well
before this flagged every file with lumps that contained the MAP as string somewhere, like palettes and such
this is kinda messy but i really do not want to dupe this huge block of code, neither do i want to convert this to ceepeepee again to mess about with templates
oh well
never seen srb2, saturn, RR or blan or anything else have this return null
there is a possibility but whatever
just continuing in such cases was wrong eitherways as it wouldve just corrupted the vres thing
never seen srb2, saturn, RR or blan or anything else have this return null
there is a possibility but whatever
just continuing in such cases was wrong eitherways as it wouldve just corrupted the vres thing
per https://git.do.srb2.org/STJr/SRB2/-/merge_requests/2784
chat offsets and character count
offsets are added to the base offset like we do for hud stuff, the og pr will directly use the cvar values for this, but wanna keep consistent with our rest
needs to be added in the menu somewhere but idk where
per https://git.do.srb2.org/STJr/SRB2/-/merge_requests/2784
chat offsets and character count
offsets are added to the base offset like we do for hud stuff, the og pr will directly use the cvar values for this, but wanna keep consistent with our rest
needs to be added in the menu somewhere but idk where
theres guards just above this which should just skip shit but for some reason the clamps still do stuff, idk man
fixes the weird grass fof in green hill
theres guards just above this which should just skip shit but for some reason the clamps still do stuff, idk man
fixes the weird grass fof in green hill
akin to RR, just toned down for smaller kart chars
also toggable ofc
theres not that many stairs in kart but this looks cute with smol bumps in the road
wish this would work on slopes but theyre kinda messed up lol
akin to RR, just toned down for smaller kart chars
also toggable ofc
theres not that many stairs in kart but this looks cute with smol bumps in the road
wish this would work on slopes but theyre kinda messed up lol
noticed sloperoll does not properly work from certain angles
so just reset rollangle if needed in K_RollMobjBySlopes since couldnt find a better place tbh
noticed sloperoll does not properly work from certain angles
so just reset rollangle if needed in K_RollMobjBySlopes since couldnt find a better place tbh
decided to have it i_error for now, not sure what exactly is the best approach here
should we just "correct" some of those instead?
vanilla probably just crashes anyways
decided to have it i_error for now, not sure what exactly is the best approach here
should we just "correct" some of those instead?
vanilla probably just crashes anyways
completely forgot about this (sry!)
the original implementation was mostly based on hughsk´s 8x8 bayer shader while the current is mostly adapted from the libretro 4x4 bayer shader
completely forgot about this (sry!)
the original implementation was mostly based on hughsk´s 8x8 bayer shader while the current is mostly adapted from the libretro 4x4 bayer shader
set using the front side upper texture field like the play sound special per "DSXXXX"
the parsing part already was there but not the actual code to make it use the specified sound for some reason lul
shouldnt break anything and is vanilla compatible!
wadfile->filename has not a fixed size, so it theoretically might be bigger than wadfilename buffer
this probably wont ever happen but better be safe than sorry honestly
wadfile->filename has not a fixed size, so it theoretically might be bigger than wadfilename buffer
this probably wont ever happen but better be safe than sorry honestly
the "already loaded" check will not first compare the md5sum, which is a very simple memcmp, and only then it will do string copies, nameonly mutation and name compare should the md5sum match
this should save quite a few unnecessary string operations since the md5 match case will rarely ever hit
the "already loaded" check will not first compare the md5sum, which is a very simple memcmp, and only then it will do string copies, nameonly mutation and name compare should the md5sum match
this should save quite a few unnecessary string operations since the md5 match case will rarely ever hit
didnt knew you could do that lul
also changes some of them to avoid any external capture by passing everything directly
this completely eliminates ALL overhead that may have been caused, which is like 3-5fps or smth lul
stuff like that should always be checked per equals/greater than just equals
in practice this shouldnt have caused any issues but its just better practice to check for greater
not for 9.3 but a later version
this is so mindelay is actually useful at all, since it relies on this, and updating this once per second is just not fast enough to make this really viable online to stabilize unstable ping
check for subsector validcount first, then if its a sky plane
so we can skip checking sector heights for sky planes, which may save a bit of maths on maps with many slopes
check for subsector validcount first, then if its a sky plane
so we can skip checking sector heights for sky planes, which may save a bit of maths on maps with many slopes
* Don't overwrite the first player's name when joining with multiple local splitscreen players. (resolves#151)
* The defaults for unprovided names are now consistently "Player A/B/C/D" as opposed to some being letter-based and some being number-based.
* Send local player info once per local splitscreen player, rather than n^2 times (where n is the number of local splitscreen players).
* Since the packet *requires* four names to be sent every time you join a server, send dummy names for local splitscreen players who aren't connecting, instead of your actual cvars (no data leakage you didn't ask for!)
* Don't overwrite the first player's name when joining with multiple local splitscreen players. (resolves#151)
* The defaults for unprovided names are now consistently "Player A/B/C/D" as opposed to some being letter-based and some being number-based.
* Send local player info once per local splitscreen player, rather than n^2 times (where n is the number of local splitscreen players).
* Since the packet *requires* four names to be sent every time you join a server, send dummy names for local splitscreen players who aren't connecting, instead of your actual cvars (no data leakage you didn't ask for!)
fixes a 4byte hole so we can fit everything important into cacheline 1
even when compiled without HWRENDER this should be a better layout
checked per pahole
fixes a 4byte hole so we can fit everything important into cacheline 1
even when compiled without HWRENDER this should be a better layout
checked per pahole
again ive never seen this hit, but the mobj gets checked right below its radius get dereferenced within the floorz/ceilingz functions which kinda annoyed me lol
as a fallback i just the floor/ceiling sectorheights, which were used before the addition of slopes
again ive never seen this hit, but the mobj gets checked right below its radius get dereferenced within the floorz/ceilingz functions
as a fallback i just the floor/ceiling sectorheights, which were used before the addition of slopes
this has an insanely rare chance of happening in certain cases (train rush map has a few spots where this is somewhat likely)
abs does not really handle -2147483648 and its result is pretty much implementation defined/ub, since we compile with fwrapv flag it would just return -2147483648 which will cause this to try and access tantoangle at a negative index
we can just return INT32_MAX here since treating either as 2147483647 would return 2147483647 eitherways
this has an insanely rare chance of happening in certain cases (train rush map has a few spots where this is somewhat likely)
abs does not really handle -2147483648 and its result is pretty much implementation defined/ub, since we compile with fwrapv flag it would just return -2147483648 which will cause this to try and access tantoangle at a negative index
we can just return INT32_MAX here since treating either as 2147483647 would return 2147483647 eitherways
decided to finally make smol stickers for the beta hud
this was never a really great solution since it made things look pretty bad at certain resolutions/scales
still keep the loading code for convenience but honestly not needed aswell at this point
decided to finally make smol stickers for the beta hud
this was never a really great solution since it made things look pretty bad at certain resolutions/scales
still keep the loading code for convenience but honestly not needed aswell at this point
also makes this alot more readable
like this most of the time we dont have to ever check the players floorz nor ceilingz at all since we check if the sector the players mobj is in is even offroad at all
nothing super big but i did see an improvement of around 1fps in my usual benchmark
also makes this alot more readable
like this most of the time we dont have to ever check the players floorz nor ceilingz at all since we check if the sector the players mobj is in is even offroad at all
nothing super big but i did see an improvement of around 1fps in my usual benchmark
on my linux system and usual benchmark setup this improves performance quite significantly (+~12fps)
this relies on jemalloc to be installed as a separate library for now and is more a convenience thing
does not fix whitescreen when switching resolutions while in intermission screen, but oh well
lets hope there will be no issues with calling D_Renderview in intermission state, but it seems to work from quick testing lul
does not fix whitescreen when switching resolutions while in intermission screen, but oh well
lets hope there will be no issues with calling D_Renderview in intermission state, but it seems to work from quick testing lul
otherwise this may still get truncated and lots of text editor also complain about a super long single line of text
also fix null ptr dereferencing into strtok should strdup return null
otherwise this may still get truncated and lots of text editor also complain about a super long single line of text
also fix null ptr dereferencing into strtok should strdup return null
now works more like i intended too by more or less scaling the pattern to be roughly the same size on each resolution and trying to reduce precision issues by using floor to convert float values to integer range
now works more like i intended too by more or less scaling the pattern to be roughly the same size on each resolution and trying to reduce precision issues by using floor to convert float values to integer range
not the most efficient but idk a better solution to this, and clipping code may cause some other undesired effects, but well were not supposed to be drawing textures with holes on single sided walls eitherways, but here we are
basically this copies columns into a buffer filled with cyan pixels, so the holes become cyan instead of nothing, which we can cut again using the twomultipatch drawers
fixes the "melt" effect on some things like spelunky or music plant (and well reading/writing oob)
kinda wasteful memory wise, and didnt even give that much of a speedup, so idk
maybe should just keep doing it at runtime and use vector storage or smth to avoid reallocs
like normal planes, polyobject planes will just reallocate their vertex buffer eitherways according to size, so that check does not make much sense, srb2 also did remove it a while ago
like normal planes, polyobject planes will just reallocate their vertex buffer eitherways according to size, so that check does not make much sense, srb2 also did remove it a while ago
apparently reusing a va list like that is ub, so we should just copy it if we want to reuse it
also fix the resize check, since vsnprintf return does not include 0 terminator which we need to account for
also make this part of dehacked.c a bit more readable lol
apparently reusing a va list like that is ub, so we should just copy it if we want to reuse it
also fix the resize check, since vsnprintf return does not include 0 terminator which we need to account for
also make this part of dehacked.c a bit more readable lol
-handle more memory allocation failures
-fix null pointer dereferences
-prevent writing out of bounds while writing filenames for D_ParseFileneeded
-prevent reading out of bounds while checking for new target in director
-fix Update_MS checking against an unitialized value in some cases
-fix assert for AddLumpToCache since strlen on non null terminated strings is UB
-cleanup and rearrange R_DrawColumn
-cleanup musicdef parser a little
all in one commit cause idk would be ugly if those were seperate ig
-handle more memory allocation failures
-fix null pointer dereferences
-prevent writing out of bounds while writing filenames for D_ParseFileneeded
-prevent reading out of bounds while checking for new target in director
-fix Update_MS checking against an unitialized value in some cases
-fix assert for AddLumpToCache since strlen on non null terminated strings is UB
-cleanup and rearrange R_DrawColumn
-cleanup musicdef parser a little
all in one commit cause idk would be ugly if those were seperate ig
- disable POLYTILE, since it does not bring any benefit and causes smaller visual issues (see silvercloud island)
- optimize find_close_polyvertex for debug/O0 builds
- add fallback case for portal and horizonline checks if cv_glpolyshape == 0
oftentimes lua scripts call CV_FindVar a fuckton of times during runtime, with many cvars this can actually tank performance more than one might think
ideally lua scripts should cache the result, but with so much stuff and servers we cant expect everyone to go through all scripts to do that
using a hashtable for CV_FindNetVar might improve join times aswell, but needs further testing to confirm
The constructor attribute causes the function to be called automatically before execution enters main (). Similarly, the destructor attribute causes the function to be called automatically after main () has completed or exit () has been called. Functions with these attributes are useful for initializing data that will be used implicitly during the execution of the program.
added "used" attribute aswell so compiler does not omit non referenced functions (i hope)
gotta test this a bit but seems cool for stuff like verstable maps
oftentimes lua scripts call CV_FindVar a fuckton of times during runtime, with many cvars this can actually tank performance more than one might think
ideally lua scripts should cache the result, but with so much stuff and servers we cant expect everyone to go through all scripts to do that
using a hashtable for CV_FindNetVar might improve join times aswell, but needs further testing to confirm
The constructor attribute causes the function to be called automatically before execution enters main (). Similarly, the destructor attribute causes the function to be called automatically after main () has completed or exit () has been called. Functions with these attributes are useful for initializing data that will be used implicitly during the execution of the program.
added "used" attribute aswell so compiler does not omit non referenced functions (i hope)
gotta test this a bit but seems cool for stuff like verstable maps
apparently demos used to send a mapcmd before instead of directly calling G_InitNew, so this function was never called which meant that timedemos always returned a wrong result first time
apparently demos used to send a mapcmd before instead of directly calling G_InitNew, so this function was never called which meant that timedemos always returned a wrong result first time
so both CONS_Alert and CONS_Debug dont have to handle and copy the varargs twice
probably makes no actual difference in practice, but i prefer it to not do pointless work
so both CONS_Alert and CONS_Debug dont have to handle and copy the varargs twice
probably makes no actual difference in practice, but i prefer it to not do pointless work
removes the "force_mobj" field, gives a suprising perf boost from my timedemo testing +6-7fps (164 - 169/170fps)
this does however will prevent the generic hook from being called if the mobj being passed ever should be NULL
This shouldnt ever happen, vanilla assumes this aswell and way worse things would happen there, but just wanted to note
as per comment, this is merely a shitty workaround for a chain reaction of bad fixed point maths
since im honestly not feeling like rewriting most of the software renderer to either operate on 64bit or float maths, we just skip drawing anything that seems completely unreasonable
taken from raptorjit
we can check the hash first to skip quite a bunch of memcmps which should be faster in most cases (hopefully but quick timedemo tests confirmed that)
the string hashing was the most hit and most spent in part of the whole game in alot of cases
replacing it with luajits algo absolutely massively improves lua performance (10-15fps in my bench timedemos!)
however idk how all this stuff exactly works so this needs alot of testing to make sure nothing breaks
ive rewritten the unaligned ptr access slightly to use memcpy for safety with some platforms that require stricter alignment
luaV_execute should compute 'ra' only when the instruction uses it.
Computing an illegal address is undefined behavior even if the address
is never dereferenced.
"this fixes numerous issues with holes in map geometry, misplaced sectors/planes, rare infinite loop hangs"
ive had ported this before but deemed it to be too slow, gonna test here again now that i also had ported it to blankart to fix udmf map rendering issues
needs some testing
stuff like that should always be checked per equals/greater than just equals
in practice this shouldnt have caused any issues but its just better practice to check for greater
seen this a bunch of times now that occasionally something tries to access uninit values from a surface info
since those are really small we just always init them now
seen this a bunch of times now that occasionally something tries to access uninit values from a surface info
since those are really small we just always init them now
not sure if this is more sane than the huge ass array from before
but atleast this is more accurate and can basically generate flashpals from any palette while also still working with all the colour and gamma adjustments
prob needs some cleanup idk this is all rather messy lol
not sure if this is more sane than the huge ass array from before
but atleast this is more accurate and can basically generate flashpals from any palette while also still working with all the colour and gamma adjustments
prob needs some cleanup idk this is all rather messy lol
iirc, if the provided palette currently in use did not provide subpalettes, this will read past the bounds of allocated memory, which aint good lol
i just dumped the white flashpal and threw it into there since idk if -file or autoload gets called before the palette gets initialised, which would carry a risk of copying more garbage, hence this big ass array
iirc, if the provided palette currently in use did not provide subpalettes, this will read past the bounds of allocated memory, which aint good lol
i just dumped the white flashpal and threw it into there since idk if -file or autoload gets called before the palette gets initialised, which would carry a risk of copying more garbage, hence this big ass array
lump name may not be null terminated here, so strlen may read out of bounds garbo
using strnlen ensures we read max 8 characters which is the name buffer size
lump name may not be null terminated here, so strlen may read out of bounds garbo
using strnlen ensures we read max 8 characters which is the name buffer size
huge amount of things in player struct and stuff related to it were basically unused
since those are technically exposed to lua and such this sure wont make it into the next saturn release
and needs a good amount of testing, if it ever makes the cut lol
prob messed stuff up somewhere but lul
been rethinking this and been doing some digging online
the unordered_map was just a quick and simple fix for performance issues in blan, but came with caveats:
- unordered_map is simple to use but not particulary great in terms of performance during lookups especially
- we needed to convert w_wad to c++ just for the lumpnumcache
- due to needing to preserve the key since they gotta outlive the scope of the function that inserts things into the map, we effectively did a string copy on each map insert and lookup
after some research came across verstable, which is basically almost the exact same as unordered map but in C while being extremely fast (even more with its builtin string hash and comparisor)
only caveat with verstable is we need to rely on a new lib, though its just a single header file, and we gotta manage ensuring the input keys outlive functionscope ourselves, which we do with strdup in this case
good thing, verstable allows to call a "destructor" specified by us whenever it removes or replaces keys in the map
this also means we only need to copy strings on insert and not on lookup anymore
all in all this is much faster while giving us the simple usage of c++ unordered_map while staying in C
due to the strdup quirk i had to slightly modify verstable to allow to take const as inputs for the getter functions even if the keys themselves are not const marked with "KEY_GET_CONST"
Verstable can be found here: https://github.com/JacksonAllan/Verstable
and is licensed under MIT which is perfect!
been rethinking this and been doing some digging online
the unordered_map was just a quick and simple fix for performance issues in blan, but came with caveats:
- unordered_map is simple to use but not particulary great in terms of performance during lookups especially
- we needed to convert w_wad to c++ just for the lumpnumcache
- due to needing to preserve the key since they gotta outlive the scope of the function that inserts things into the map, we effectively did a string copy on each map insert and lookup
after some research came across verstable, which is basically almost the exact same as unordered map but in C while being extremely fast (even more with its builtin string hash and comparisor)
only caveat with verstable is we need to rely on a new lib, though its just a single header file, and we gotta manage ensuring the input keys outlive functionscope ourselves, which we do with strdup in this case
good thing, verstable allows to call a "destructor" specified by us whenever it removes or replaces keys in the map
this also means we only need to copy strings on insert and not on lookup anymore
all in all this is much faster while giving us the simple usage of c++ unordered_map while staying in C
due to the strdup quirk i had to slightly modify verstable to allow to take const as inputs for the getter functions even if the keys themselves are not const marked with "KEY_GET_CONST"
Verstable can be found here: https://github.com/JacksonAllan/Verstable
and is licensed under MIT which is perfect!
this version changed so that many standard functions now propagate the constness of its input pointers
to not cause warnings for everyone on older versions this is now a really dumb macro lol
we *rely* on a bunch of gnu extensions so its better to explicitly set this
yes in theory we fully comply with c23/gnu23 and saturn compiles fine under that, but since its still fairly new theres alot of maschines that still dont support it :chaosleep:
we *rely* on a bunch of gnu extensions so its better to explicitly set this
yes in theory we fully comply with c23/gnu23 and saturn compiles fine under that, but since its still fairly new theres alot of maschines that still dont support it :chaosleep:
this version changed so that many standard functions now propagate the constness of its input pointers
to not cause warnings for everyone on older versions this is now a really dumb macro lol
every "flag" set by signal handlers must be of type "volatile sig_atomic_t"
everything else may fail to be correctly set, read or get optimized away which rendered this basically useless
every "flag" set by signal handlers must be of type "volatile sig_atomic_t"
everything else may fail to be correctly set, read or get optimized away which rendered this basically useless
the earlier approach still raised the default signal within this, which basically just skipped everything and ended up NOT calling I_Quit at all
Basically this is to ensure we dont call I_Quit at all from a signal handler as it is NOT async safe and can cause serious issues like deadlocks and such, instead SIGINT and SIGTERM will just signal the main loop/thread to safely call I_Quit instead
the earlier approach still raised the default signal within this, which basically just skipped everything and ended up NOT calling I_Quit at all
Basically this is to ensure we dont call I_Quit at all from a signal handler as it is NOT async safe and can cause serious issues like deadlocks and such, instead SIGINT and SIGTERM will just signal the main loop/thread to safely call I_Quit instead
taken from raptorjit
we can check the hash first to skip quite a bunch of memcmps which should be faster in most cases (hopefully but quick timedemo tests confirmed that)
the string hashing was the most hit and most spent in part of the whole game in alot of cases
replacing it with luajits algo absolutely massively improves lua performance (10-15fps in my bench timedemos!)
however idk how all this stuff exactly works so this needs alot of testing to make sure nothing breaks
ive rewritten the unaligned ptr access slightly to use memcpy for safety with some platforms that require stricter alignment
luaV_execute should compute 'ra' only when the instruction uses it.
Computing an illegal address is undefined behavior even if the address
is never dereferenced.
- cap fps after rendering but before blitting (helps in cases where rendering takes a long time)
- attempt to resync fpslimiter with ticking after fpscap change to fix phase issues and potential display lag
this is shit so 9.3 will not have any of this, sad!
lumpnumcache can be case sensitive W_CheckNumForName should also look for uppercase stuff and W_LumpExists is case sensitive anyways
this avoids having to always account for case (toupper/tolower) during hash and string comparisons and even allows us to even directly compare our strings instead of using fastcmp (std::strings allow this!)
from some benchmarking externally this makes this faster quite a bit
lumpnumcache can be case sensitive W_CheckNumForName should also look for uppercase stuff and W_LumpExists is case sensitive anyways
this avoids having to always account for case (toupper/tolower) during hash and string comparisons and even allows us to even directly compare our strings instead of using fastcmp (std::strings allow this!)
from some benchmarking externally this makes this faster quite a bit
this was for an older iteration where it ran the loop until it hit the target per condition, keeping like this may cause issue if the loop exits per condition instead of the return block
now we return from within the loop
as per comment, this is merely a shitty workaround for a chain reaction of bad fixed point maths
since im honestly not feeling like rewriting most of the software renderer to either operate on 64bit or float maths, we just skip drawing anything that seems completely unreasonable
this completely rewrites the old simple sleep based limiter with
whatever tf i came up with at 2am
this almost completely gets rid of any jitter, stutter, uneven framepacing and missing the cap
it might be slightly less efficient due to busy waiting more, but so far it seems to be about the same
CV_SetValue will call the callbacks each, which means when it sets the width, the height cvar will not be updated yet, which most definitely will not be in the modelist, so it will add it regardless
CV_SetValue will call the callbacks each, which means when it sets the width, the height cvar will not be updated yet, which most definitely will not be in the modelist, so it will add it regardless
prefer to use standard lib functions if possible
lrint does the same thing (well ofc as long as no one touches the rounding direction löl) and is even quite a lot faster (though this is negligible in this case)
prefer to use standard lib functions if possible
lrint does the same thing (well ofc as long as no one touches the rounding direction löl) and is even quite a lot faster (though this is negligible in this case)
honestly be better to just completely switch over to 64bit maths, or even better floats....
this is mostly just bandaids but seems to make software more "visually stable"
on my linux system and usual benchmark setup this improves performance quite significantly
i currently have no real means to check how windows behaves, since this does not work with wine
removes the "force_mobj" field, gives a suprising perf boost from my timedemo testing +6-7fps (164 - 169/170fps)
this does however will prevent the generic hook from being called if the mobj being passed ever should be NULL
This shouldnt ever happen, vanilla assumes this aswell and way worse things would happen there, but just wanted to note
Older versions break and have unstable ids on Windows, cant check for linux but ill just add a version check at this point
This was part of updating sdl with v9, which got reverted due to other issues but this was not reverted oopsie
-add LTO option, enabled by default
-set optimization level to O3 and O0 for debug builds
-add ASAN and UBSAN options
-always compile with gnu debug symbols
dont call rand within the loop, use xorshift instead
while not massive, we dont need to call rand thousands of times, the xorshift is visually indistinguishable
this is still rather slow due to the crapton of draw calls and should best be replaced by a shader or something
dont call rand within the loop, use xorshift instead
while not massive, we dont need to call rand thousands of times, the xorshift is visually indistinguishable
this is still rather slow due to the crapton of draw calls and should best be replaced by a shader or something
whoops, not sure why that was even done like that
string.c will include strcasestr.c and SRB2_HAVE_STRLCPY will ensure eitherways we dont use the included strlcpy stuff
this shouldnt account for highreshudscale at all
on very high resolutions the bars are still only half size, but atleast they dont become minuscule or just dont draw at all
also ensures both bars are clamped, on some resolutions sometimes they just go out of visible screen range
this shouldnt account for highreshudscale at all
on very high resolutions the bars are still only half size, but atleast they dont become minuscule or just dont draw at all
also ensures both bars are clamped, on some resolutions sometimes they just go out of visible screen range
this is incredibly ugly and hacked together
theres some weird culling issues and shit doesent really "scale" with different resolutions which needs to be fixed
but it kinda works
this is incredibly ugly and hacked together
theres some weird culling issues and shit doesent really "scale" with different resolutions which needs to be fixed
but it kinda works
toggles certain effects, which may be troublesome to some players
-disabled hyudoro flashing, instead makes player translucent
- Makes rainbow colour effects, such as invul, change colours very slowly
- Disables underwater and heatwave screen effects
- Disables palette flashing
- Disables vhs effect
not the most pretty implementation, but im lazy and this works
feel free to suggest more things
toggles certain effects, which may be troublesome to some players
-disabled hyudoro flashing, instead makes player translucent
- Makes rainbow colour effects, such as invul, change colours very slowly
- Disables underwater and heatwave screen effects
- Disables palette flashing
- Disables vhs effect
not the most pretty implementation, but im lazy and this works
feel free to suggest more things
toggles certain effects, which may be troublesome to some players
-disabled hyudoro flashing, instead makes player translucent
- Makes rainbow colour effects, such as invul, change colours very slowly
- Disables underwater and heatwave screen effects
- Disables palette flashing
- Disables vhs effect
not the most pretty implementation, but im lazy and this works
feel free to suggest more things
properly match the old linear lookup by returning the FIRST match for doomednum
also shrinks the array, doomednum max is 4095, no need for such massive array, also fixed a off by
should fix some join desynchs and desynchs on certain maps
properly match the old linear lookup by returning the FIRST match for doomednum
also shrinks the array, doomednum max is 4095, no need for such massive array, also fixed a off by
should fix some join desynchs and desynchs on certain maps
bunch of smaller issues before, no real checks for strltol and potential free on a null pointer lul
also skips replays with shorter than 10 char names and handles errors better
bunch of smaller issues before, no real checks for strltol and potential free on a null pointer lul
also skips replays with shorter than 10 char names and handles errors better
This seems to improve performance on maps with moderate to lots of fofs quite a bit.
On maps with only a few fofs, this makes no difference or has very very little regression
Need to test and check if there are any visual errors, but so far everything seems good
no need to constantly reallocate new memory
we dont have renderer switch, and the next level will render drawnodes anyways
those wont grow super big also, so theres no big worry about wasting tons of memory
yes i like ceepeepee vectors, how can you tell
While i assume this to be fine currently, i quite frankly dont trust the srb2 codebase enough aswell as preventing any future issues if there should ever be need to switch locales, since toupper WILL change behaviour in such cases which does not qualify as pure
While i assume this to be fine currently, i quite frankly dont trust the srb2 codebase enough aswell as preventing any future issues if there should ever be need to switch locales, since toupper WILL change behaviour in such cases which does not qualify as pure
this might let the compiler optimize aways subsequent calls in some cases
strcmp etc from glibc also does it
prayin nothin changes the locale at runtime lmao
so far this seems to cut the time searching for an existing colormipmap in half, needs some testing as this is finicky code that may leak badly if not handled correctly
models currently broken, for reasons above
This seems to improve performance on maps with moderate to lots of fofs quite a bit.
On maps with only a few fofs, this makes no difference or has very very little regression
Need to test and check if there are any visual errors, but so far everything seems good
fixes an issue for me which led to having the game threads getting stuck when sending an interrupt signal to the game due to some thread issues with the sdl subsystems
shoutout to dsda doom for this
well this still aint working all to great, but atleast this allows me to quit the game if it gets stuck without having to always send a kill signal to it
copy pasted from what the dedicated build does
fixes an issue for me which led to having the game threads getting stuck when sending an interrupt signal to the game due to some thread issues with the sdl subsystems
well this still aint working all to great, but atleast this allows me to quit the game if it gets stuck without having to always send a kill signal to it
copy pasted from what the dedicated build does
we dont use it for anything, we also cannot use it for anything.
Due to massive amounts of unterminated string being passed to everything
So we dont need to waste memory and resources
we dont use it for anything, we also cannot use it for anything.
Due to massive amounts of unterminated string being passed to everything
So we dont need to waste memory and resources
in two parts:
- Use our lumpcache lookup first (our unordered map), BUT since it is case insensitive we extract our lump out of it to do another case sensitive name compare
- In the manual lump seach falltthrough case, we can also check against the string lenghts and hash (its case insensitive but will still reject differing names, same with stringlenght)
this improves the performance of the leaderboard map browser quite a bit and everything else using v.patchExists
needs testing if actually better
but the old lumpnumcache was basically useless due to being incredibly small
even just booting up the game we have around 1000 entries already
this hopefully should still be faster than potentially going through ALL lumps in ALL wads we have loaded to find the lumpnums
not sure if longnames should get any special handling like before, but i dont think it really matters if theyre long honestly
thanks ceepeepeereference for the basis of this
in two parts:
- Use our lumpcache lookup first (our unordered map), BUT since it is case insensitive we extract our lump out of it to do another case sensitive name compare
- In the manual lump seach falltthrough case, we can also check against the string lenghts and hash (its case insensitive but will still reject differing names, same with stringlenght)
this improves the performance of the leaderboard map browser quite a bit and everything else using v.patchExists
needs testing if actually better
but the old lumpnumcache was basically useless due to being incredibly small
even just booting up the game we have around 1000 entries already
this hopefully should still be faster than potentially going through ALL lumps in ALL wads we have loaded to find the lumpnums
not sure if longnames should get any special handling like before, but i dont think it really matters if theyre long honestly
thanks ceepeepeereference for the basis of this
i suck at explaining so just trust. :chonkbuncle:
Game sound handling has no idea which sound it is playing/checking, so a sound that ended frees its slot and it might get occupied again without the game knowing
so just encode the channel number into the sound so we can actually check
Apparently in some cases the server will connect to itself, in this case the server tries to send itself the savegame, leading to a crash in some cases. oops
- expose SAVEGAMESIZE
- pass node number to SV_AddWaitingPlayers (saves iterating through all 128 net nodes everytime a player joins) lifted from RR
- move all packet handling to the packet handlers
- Reorder packethandling switches a little, so common/important packets get checked first
- fix wrong clamp for realfirsttic that was too early
- add nowtime division by NEWTICRATERATIO (no change unless ticrate changes)
shouldnt change the behavior much as we wont see anything without a camera, but this is explicit about what exactly is wanted (i.e. thiscam may be null, we only check due to null deref, we only care about if freecam is active)
shouldnt change the behavior much as we wont see anything without a camera, but this is explicit about what exactly is wanted (i.e. thiscam may be null, we only check due to null deref, we only care about if freecam is active)
- expose SAVEGAMESIZE
- pass node number to SV_AddWaitingPlayers (saves iterating through all 128 net nodes everytime a player joins) lifted from RR
- move all packet handling to the packet handlers
- Reorder packethandling switches a little, so common/important packets get checked first
- fix wrong clamp for realfirsttic that was too early
- add nowtime division by NEWTICRATERATIO (no change unless ticrate changes)
phew so every line now has two names
otherwise we cannot fit everything and anyone into this anymore
this even allowed to put back the tooltip at the bottom
i still want to redo the credits completely at some point with some cool stuff though
phew so every line now has two names
otherwise we cannot fit everything and anyone into this anymore
this even allowed to put back the tooltip at the bottom
i still want to redo the credits completely at some point with some cool stuff though
- Fix serverlist results not being properly reset, which lead to reopening/refreshing the serverlist to show the old state, selecting one of those "old" servers then lead to just connecting to nothing
- Fix the resfresh button making servers disappear if hit too often too fast (from srb2)
https://codeberg.org/srb2classic/srb2classic/commit/3acc312923da0fe5e07c0517d9bff9e8b657b1eb
- Fix serverlist results not being properly reset, which lead to reopening/refreshing the serverlist to show the old state, selecting one of those "old" servers then lead to just connecting to nothing
- Fix the resfresh button making servers disappear if hit too often too fast (from srb2)
https://codeberg.org/srb2classic/srb2classic/commit/3acc312923da0fe5e07c0517d9bff9e8b657b1eb
due to ghosts occasionally ending to early and game interpreting them as still valid uhhhhh
lets pray this wont explode or cause any weird issues......
credits to RR
REVERT THIS ONCE I GO AND FIXUP THE REPLAY MESS
due to ghosts occasionally ending to early and game interpreting them as still valid uhhhhh
lets pray this wont explode or cause any weird issues......
credits to RR
REVERT THIS ONCE I GO AND FIXUP THE REPLAY MESS
clips sprites that are out of our view, especially with precip this may lead to significant speedup in certain cases
huge thanks to indev for helping with this <3
huge thanks to dsda-doom for the maths needed!
clips sprites that are out of our view, especially with precip this may lead to significant speedup in certain cases
huge thanks to indev for helping with this <3
huge thanks to dsda-doom for the maths needed!
in both cases "R_Subsector" already got the frontsectors ceiling z, so no need to get it again within R_Prep3DFloors
should save some P_GetSectorCeilingZAt per frame
in both cases "R_Subsector" already got the frontsectors ceiling z, so no need to get it again within R_Prep3DFloors
should save some P_GetSectorCeilingZAt per frame
since we mostly use it in fixed point maths, this just makes alot more sense
moving it into inline functions ensures that in C code this wont evaluate its arguments multiple times
since we mostly use it in fixed point maths, this just makes alot more sense
moving it into inline functions ensures that in C code this wont evaluate its arguments multiple times
instead of SDL_GetDesktopDisplayMode, as the former only returns the display mode from when the window was created, which might not reflect the actual current desktop mode.
Maybe fixes some resolutions being incorrectly reported asa having visual issues
instead of SDL_GetDesktopDisplayMode, as the former only returns the display mode from when the window was created, which might not reflect the actual current desktop mode.
Maybe fixes some resolutions being incorrectly reported asa having visual issues
use batching system without sorting for order sensitive things like sprites and transparent stuff
even despite not being "optimally" sorted, drawing them in one go, instead of directly still gives a nice speed increase in certain cases (on my ryzen 5600 i get around 120fps+ on teiai towers starting area!)
range from 0.25 to 4
to account for all types of controllers and such
base 1 was set around what felt good on my dualsense, not entirely sure if this is the best baseline to go with
otherwise it could still be adjusted
range from 0.25 to 4
to account for all types of controllers and such
base 1 was set around what felt good on my dualsense, not entirely sure if this is the best baseline to go with
otherwise it could still be adjusted
big oopsie from my side
this caused textures that werent translucent to be marked with translucent in a bunch of cases, which led to them being rendered in a slower path
big oopsie from my side
this caused textures that werent translucent to be marked with translucent in a bunch of cases, which led to them being rendered in a slower path
I_LocateWad returns mallocd memory that needs to be freed
and our home search does not need a tmp ptr
just do as we did before and sprintf it into returnwadpath
also check home directory before the hardcoded lists like before (might speed up startup a little on nix)
also cleanup iwad search in dedi builds and apply everything there aswell
I_LocateWad returns mallocd memory that needs to be freed
and our home search does not need a tmp ptr
just do as we did before and sprintf it into returnwadpath
also check home directory before the hardcoded lists like before (might speed up startup a little on nix)
also cleanup iwad search in dedi builds and apply everything there aswell
- skincolors are uint8 type not uint16
- ensure desired colour is within skincolor range
- rename G_GetSkinColor to G_GetSkinColorForGamepad
- replace pointless array with single variable for current color in D_DeviceLEDTick
- remove pointless call to G_GetSkinColorForGamepad when hotplugging gamepads (G_SetPlayerGamepadIndicatorColor will call it itself when 0/skincolor_none is passed)
- skincolors are uint8 type not uint16
- ensure desired colour is within skincolor range
- rename G_GetSkinColor to G_GetSkinColorForGamepad
- replace pointless array with single variable for current color in D_DeviceLEDTick
- remove pointless call to G_GetSkinColorForGamepad when hotplugging gamepads (G_SetPlayerGamepadIndicatorColor will call it itself when 0/skincolor_none is passed)
no need to constantly reallocate new memory
we dont have renderer switch, and the next level will render drawnodes anyways
those wont grow super big also, so theres no big worry about wasting tons of memory
yes i like ceepeepee vectors, how can you tell
honestly doesent make that much sense in most cases to grow capacity * 2 (slightly misunderstood some stuff on implementation)
and in other cases dont need to manually check for resize
honestly doesent make that much sense in most cases to grow capacity * 2 (slightly misunderstood some stuff on implementation)
and in other cases dont need to manually check for resize
we do culling per our viewmatrix since a while, which wasnt properly set up for portals beforehand and used whatever was last which was then incorrectly applied to portal culling :chaobaba:
we do culling per our viewmatrix since a while, which wasnt properly set up for portals beforehand and used whatever was last which was then incorrectly applied to portal culling :chaobaba:
players first, then kart items, shadows and then some srb2 things that are commonly used
makes more sense to check for all of those first everywhere, so we may skip a crapton of pointless checks in many cases
players first, then kart items, shadows and then some srb2 things that are commonly used
makes more sense to check for all of those first everywhere, so we may skip a crapton of pointless checks in many cases
we check against MAXMODEDESCS, which is the maximum of modes the videomode can list
just in case we really get a display with a fuckton of resolutions, which most likely wont ever be the case though
this just removes the smallest modes from the list (accounting for the canonicals), to keep things simple
we check against MAXMODEDESCS, which is the maximum of modes the videomode can list
just in case we really get a display with a fuckton of resolutions, which most likely wont ever be the case though
this just removes the smallest modes from the list (accounting for the canonicals), to keep things simple
- use sqrtf for fade/tint alpha for shaderless light calc
- save recalcing the cosine/sine from angle on angled flats 3 times in HWR_RenderPlane
- precalc float "int32 min/max "
- Add saturnpak, saturnjoin, screenfbo settings
- Add libbacktrace stuff (hope thats correct)
- set openmpt, discordrpc and libbacktrace as optional libs
- move asset hashes to d_main, fixing CMAKECONFIG (which fixes commit stuff)
- propely handle md5 sources
- set "-rdynamic" and "-g" (-g1 on non debug builds) so libbacktrace can get proper backtraces
it actually compiles an executable that even starts!!!
TODO:
- fix windoze lib stuff, we dont use cpm
- fix git commit related stuff (shows just "illegal" on titlescreen)
- readd saturn specific things like saturnpak, fbo etc
- fix CMAKECONFIG
dont constatnly recheck the uh input players distance to waypoints for all players to check against
saves around 50-350 distance checks per tic (depends on the map)
this is only so ugly and hacky because we need to preserve a vanilla bug that cuts the waypoint distance in half for the last player in the player arrays lmao
much thanks dsda-doom for most of the code for this
TODO:
- resolution menu needs to refresh if the list changes
- clean up
- handle custom resolutions more sane
- figure out the best maximum resolution list size the menu can display
much thanks dsda-doom for most of the code for this
TODO:
- resolution menu needs to refresh if the list changes
- clean up
- handle custom resolutions more sane
- figure out the best maximum resolution list size the menu can display
i watched a random youtube video at 3am moment
this mostly gets rid of the global timestate in favor of tracking the time from gamestart to calling I_GetTime/Frac
this is more in line with most doom source ports handle it
continue the loop, not return, it might just be an empty line, so returning might break some luas
0 lenght would make realloc allocate nothing at all, so just skip it
there were a bunch of cases where inf and nan float results were casted and used with integer things, which well is undefined behavior in c
yes i did use ceepeepee for that crap, cause the cases i found both gladly were ceepeepee files and this wouldve been really annoying without templating types
if someone really wants that crap to use outside ceepeepee, feel free to make a bunch of wrappers cause im too lazy for that stuff
actually replace everything correctly
my dumbass forgor about the fast both strcmp and stricmp matter in sort stuff so we cannot use the fastcmp stuff there, which means we should not redifine stricmp as fasticmp in case something relies on that behaviour ugh
while this is more accurate to how the player experienced stuff in the actual game, this also can be somewhat jittery and stuttery depending on the net conditions the replay was recorded in, so make this toggable if someone wants it
i.e. since we allow texture filtering on translucent textures now, the min filter may specifcy one of the mipmap filters, this means we NEED to call GL_GENERATE_MIPMAP and set the LODs for them, otherwise no texture will be generated
alternatively we could do a bunch of special cases for the mipmap filters, but this is simpler
fixes an issue where in some rare cases, the game may get stuck in a weird limbo state due to the text command buffer being full and never be cleared, so netxcommands can never be executed
we currently dont need this, gl_textures were already initialized due to being "static" (still explicitly init it to NULL)
this would only be useful for renderer switching, which we dont have
struct with two sets of maptextures, one for normal another for encore textures
functionally identical, hopefully also performancewise
more explicit than doing this with just one set and indexing stuff :bloblcatpats:
This used to be used for `P_RelinkPointers()`, but was superseded by the far saner mobjnum. HOWEVER, its lingering effect was to leave `mobj->info` in an invalid state until a later `P_FinishMobjs()` was called. This is memory unsafety :D
After removing the last remnants of this ancient hack, it is now once again possible to connect to a server without crashing immediately. However, I did get a crash after a few seconds, so there is definitely still *something* nasty going on under the hood.
* Make sure the consvar's properties are all initialised to zeros as defaults
* Error if the consvar is not given a name
* Error if the consvar has CV_CALL but no call function
* Error if the consvar has CV_NOINIT but not CV_CALL
See c92378fa and a7e20f70. I didn't realize that light
userdata's metatable is shared--like numbers or strings.
So it cannot be paired with a metatable.
I also made a few minor tweaks to Lua cvars, other than
accounting for the double pointer in the userdata.
we only need R_ExecuteSetViewSize from splitscreen_onchange, the rest doesent do anything due to SV_StopServer call earlier setting cl_mode to CL_ABORTED
SV_StopServer also calls Y_EndIntermission and Y_EndVote if necessary
by reusing the special sector calculated earlier, this didnt change for when its checked another time
also one fixedmul in P_SceneryTryMove in some cases
allow sending a fake player to the ms and serverbrowser when your dedicated server is empty
effectively functioning as a "seed" player without manual intervention and occupieng a server slot
- do pointerdiff outside the loops, no need to do them 16 times per span
- cache tiltilighting and planezlight, mark as const and restrict, should help he compiler deciding on better optimizeations for this
lots of confusion
but it does more brightness adjustment than gamma adjustments, yes this does some gamma correction but not user changable global gamma adjustments like globalgamma
uhhh
:shook:
use the CLEANUP macro everywhere
init some things that may not be initialized
and make this more readable
lets hope didnt break anything Zzz...
TODO: if there are still issues with demo records and stuff crashing might consider porting some of the fixes from RR
just treat them as "normal" buttons instead of manually polling for them
alot cleaner and gets rid of yet another polling loop
also clean up some other stuff
needs to be tested with multiple controllers in splitscreen but cba to do that atm
- We had two ways of ending the intermission, but only one would actually be used, and it resulted in code duplication.
- Combine the two ways.
- Disable the reached-but-didn't-do-anything-before-now code path for setting endtic.
- pass "-g" on mingw builds generally after everything (needs testing)
-use "libs" instead of "LDFLAGS" (identical purpose)
- pass "mno-ms-bitfields" on gcc, shouldnt be really needed but just in case
on 32bit targets this will just compile into two 32bit copies which gcc cant optimize as well as it can with the byte copy (it seems to love to do some AVX stuff atleast in my tests)
so this is only useful for 64bit capable platforms (compiler does not seem to do 64bit copys for the byte copy case, so this ends up being faster)
apparently some gl drivers may use a slower path for streamed textures that only get partly updated, this tricks them into thinking this did a "full update" and resulting in using a faster renderpath
- Empty `demo.titlename` case
- Don't try to save demo of name `.lmp`
- Doesn't fall back to anything, because emptying out the name field can be reasonably treated as not wanting to save
- `demo.titlename` consists only of invalid characters
- Don't try to save demo of name `-.lmp`
- Falls back to the default demo title, because the user clearly wanted to save and just happened to provide invalid text
remove
- broken viewborder code (if we really want it back for some reason, we should rather port RR´s fixed version of it)
- remove console clipping code for software (this was broken eiherway)
- remove hud message clearing stuff
- remove renderscreen and linesize variables (they just pointed to vid.screen and vid.widht)
this is just to have it cleaner and less code bloat
the resizing loop will almost never trigger, 1meg is enough to even rotate gigantamax eevee without needing to grow
R_LoadTextures was reading in the entirety of every
texture lump, now it only reads the 8 byte PNG header.
This saved more than 1 second for me (1.68 s -> 0.24 s).
PNG still need to be read in entirely to check their
dimensions; I didn't bother looking into optimizing it
since we don't have many PNG textures right now.
I was running into a memcpy of overlapping memory regions
in R_RenderMaskedSegRange.
- This is because of the reallocation of lightlists, which
uses Z_Frame_Alloc.
- The memory pool that Z_Frame_Alloc draws from is cleared
each frame.
- g_dc was not cleared though, so when the lightlists were
reallocated, it'd try to copy from invalidated pointers.
- Access to invalid pointers within the memory pool does
not cause a segfault directly (because the memory pool
is allocated once). However, a memcpy involving such an
invalid pointer leads to overlap, which may cause memory
corruption.
- Fix negative y offsets for both normal and y-flipped patches
- simplify column wrapping/nonpow2 handling
- Single-patch textures: print an error if patch header is missing, cease memory errors
sadly does not fix our invalid columns we get occasionally
- use a std::vector for the tiltlightbufffer, only for easier checking if it needs to be resized from resolution change
- move stuff into its own function
- simplify R_CalcTiltedLighting
no functional change, no performance improvement, just looks neater
currently to hide the commit string from titlescreen on release builds
could be used for other crap
wish could use comptime to autogenerate this, but it runs after compile & linking
-curl-proxy will set proxy used by curl for masterserver requests and
http downloads
-curl-header can receive multiple arguments (like -file), and can either
edit, replace or remove headers from http requests
(srb2kart -curl-header "New-Header: Some Value" "Accept: */*" "User-Agent:"
In this example, New-Header will be added, Accept header will be edited
and User-Agent header will be removed)
in theory this should improve levelload times and reduce memory usage?
gotta see if it really does, visually so far there seems to be no difference at all
- dont check for polyflags (rendersides) inside HWR_Addline, move to HWR_AddPolyObjectSegs
- save some sector checks by assigning pointer HWR_RenderPlane
- check for numpolys instead of numPolyObjects in HWR_Subsector (will only be "true" if theres polyobjs in currently traversed subsector instead of when polyobjs are generally on the map)
mostly delet some "dead" code
use pathisdirectory for filebrowser to declutter code
properly declare FUNCNORETURN and ATTRNORETURN for some quit functions
- Move the backtrace and signal stuff into one "block" in both i_system files
- print the current platform into the crashlog
- dedupe code a little
- make crash messages slightly more understandable
- handle more signals (if they exist)
mostly taken from https://git.do.srb2.org/STJr/SRB2/-/merge_requests/2732
mostly taken from https://codeberg.org/srb2classic/srb2classic/pulls/156
manually done to ensure we only port things that are guaranteed to not cause any potential desynchs
we should probably run this ourselves sometimes aswell
this was added ages ago and broke server joining with actual modifieng addons that were not added locally
W_InitFile should already handle this and mark local addons not as important, which would skip those checks eitherway
atleast thats what im hoping
instead of like, constantly checking stuff each frame
Now we check whenever we change the menu entry or open/close the chat or console instead and set sdl textinput mode directly and accordingly no more weird hacking around
this is similar to how srb2classic handles it, just a bit simplified (i dont wanna touch anything menu related if it can be avoided lmao)
this hopefully should resolve any weird remaining issues (lets hope i didnt miss some wonky edge case ugghhh)
TODO: update sdl2 lib on windows to fix issues on sdl side with certain layouts
just always initally allocate it with 1mb size, this is enough for just about everything including gigantamax eevee
if thats not enough, just double our capacity until it fits what we need
this way we save effectively reallocating 99% of the time
renderbatches just needs to be moved, sprite drawers already used preparepolygon
this seems to improve performance accross the board, no matter how many sprites there are, but the benefits becomes greater the more sprites there are
in some cases gaining up to 200fps! (precip especially benefits from this)
needs some testing to see if this may cause issues with sorting, etc
also add safety to the portal stencil stuff, if that fails
everything gl2.0 and newer is not critical and will just prevent some effects from working so that does not need to error loudly
delet michealsoft
psure this was broken since quite a long time, now since we use quite a bunch of GNU extensions (and actually rely on the cleanup attribute), supporting this in any way is just too much, so remove everything to declutter the codebase
I don't wanna hear about MSVC... or C++...
This fixes NUMEROUS memory leaks introduced by G_ReadDemoHeader,
which I was utterly oblivious to up until an hour ago
this should allow older gpus to use the feature aswell, not super clean but seems to work
TODO: refactor this whole crap, switch to seperate read and draw to use blitting and make this multisampling compatible so we can get rid of the messy "downsample" code and have this active by default
most of the actual spawn is split into P_SpawnNiGHTSHoop, which takes arguments to determine if to spawn just a hoop or its collision detectors
(if you wonder why this takes a mobj pointer to pointer is due to collision detector need the former hoops last mobj to link into)
- also actually fixes midgame join crash (hoop hnext was directly nulled instead of using p_settarget)
- added some extra safety checks
- reduced the amounts of r_pointinsubsector calls for things that used to go through this function
vissprite_t now keeps pointer to precipmobj directly instead of just a simple boolean check
this has multiple benefits
the mobj_t struct now can be reorderer and modified as pleased without having to worry about precipmobj struct layouts since all precipmobj -> mobj casts are eliminated
this allows to remove a massive amount of fields from precipmobj struct which never were used massively reducing the footprint of a precipmobj thing
kinda wish there was a neat way to template function headers to take different types for the same arguments in C to reduce code duplication, but this glady is atleast a rather small case
precipmobjs always spawned with AST_COPY blendmode which failed the check, but they are supposed to be translucent when rain
restore the correct behaviour
the evaluation order is undefined, so its up to compiler in which order to call these
P_Random functions modify the randomseed each time theyre called, which can lead to different outcomes (thus desynchs) on different platforms, compilers, compiler versions etc.
so match up with the most common which is last to first (seemingly the order gcc on nix and windows handle it)
this just takes out the cleanup code from P_SetupLevel so it can be called from within D_ClearState and all the mapdata will be freed when going back to the main menu
Not super crazy and really necessary in kart, but why not tbh
this is mostly based on what RR does
this will get converted to fixedpoint anyways and is only used in ONE function at all to determine texture x offsets in gl
yes this does get readjusted in adjustsegs if our glsegs differ, but this should be so marginal so save us the work at mapload
gotta test and see if i can ever see a difference
this is from google before the snappy compression library, supposedly 100% compatible with existing lzf data both in compressing and decompressing
but supposedly alot faster doing both
we not make copies of lines, sectors and vertices on mapload that have the spawn state, so those fields are redundant now
also fix copy paste that prevented ceiling flat angle to check for the wrong thing
- P_GetLocalPlayerNumForNum returns the playernumber for a given index
- P_IsLocalPlayerNum returns if a playernum is local to the maschine
- replaced most if else chains from checking splitscreen things with loops using P_GetLocalPlayerNumForNum and P_GetLocalPlayerForNum
-use parts of RR´s implementation to get rid of the windows specific code and generally simplify this
- also use SRB2´s symlink detection as its simpler and saves one lstat call per searched file
- made levelfadecol a local variable
- renamed all the "Raw" functions
- moved axis mapthing spawn into the mapthing spawn function
- moved mapthing load to mapdata load, saves opening the THING virtual lump twice
- split out linedef init out of the loop it now gets done within linedef load code saving the hassle of iterating through all the lines twice
- removed a bunch of dead code and useless variables
- moved virtual resource free to after the mapdata has been loaded completely
- sidedef loop now increments pointer instead of reassinging it each iteration
- lastloadedmaplumpnum now gets checked for LUMPERROR instead of INT16_MAX since W_CheckNumForName returns LUMPERROR if lump was not found
like this we dont have to reopen the mapdata 3 times each time we prepare a netsave
also allows us to directly compare sector and line properties
this should save a bit of time when someone joins or resynchs with gamestate system
this is based on some UDMF work from srb2
The level will only reload during a gamestate reload if the map is horribly mismatched somehow. Minor differences in level state are already handled by other parts of the reload, so doing this on *every* reload wastes lots of time.
Replaces the old freelist solution with the LevelPool, which
dramatically reduces the number of allocations needed for mobj and
precip sector assignment. In measurement, this cuts down the time taken
for spawning precipitation by 50%.
This should substantially reduce the number of malloc/free calls made to
create and destroy mobjs, especially during level load and net
save/load.
memory_resource standard header is not available on the OSX deployment
target we are using, so I had to write my own fixed size pool allocator.
- Bake W_VerifyFile in, since it was a stub never called anywhere else
- Make it operate off file handles, since the following locations quickly filesearch'd more than once in quick succession.
- W_InitFile
- Command_Addfile
- Remove spurious call from W_InitMultipleFiles for `-file` startup param
This isn't an optimization for the mobj pointer list, but it is an
optimization for level interpolators, which previously made N
allocations for N non-mobj thinkers. Now those allocations are amortized
according to std::vector's storage.
This could still be further cleaned up to be more C++-ey.
fixes numerous issues, like zonetitle not appearing on bots and serverinfo screen
and generally making this more sane by appending stuff if needed
also fixes "Zone" not displaying in serverinfo screen
just set everything to transparent pixel 247 (0xf7)
so we neither write nor read garbage data and just can cut it out as transparent during pixel to patch conversion
tries 5 times then gives up
this is just since vanilla clients do not send anything back to us so this would endlessly retry which is pointless
can be adjusted if needed
its suprisingly common for the test coords to not change between calling those functions, so we can potentially save us alot of R_PointInSubsector calls
Need to check for branch prediction slowdowns, but from some quick timedemoing, this speeds up things a bunch
slightly newer target, should still be compatible enough with anything from 2009 and onwards
may help with compiler optimizations
needs some testing
32bit builds remain unchanged as they are intended purely for compatibility
this also gets called at the start of the tic
and sets a bunch of rendering crap eitherways
so we can save another thinker loop and a bunch of checks with this
bit of perf gain, 3-4fps on that awful hadal trench timedemo
this is slightly faster and the recommended way of doing this
apparently stat on windows has to emulate some POSIX stuff for that which may slow it down
by adding a blacklist of folders
logs, luafiles, replay etc shouldnt ever contain addons so those can be skipped entirely
this massively speeds up searching for addons on windows
also will make findfile try to search in the designated addon folders first so it doesent look in the home or kart folders before it
this is probably not the best way to do things
but idk what im even doing, im not a coder just some chao who likes to sleep all day
mobjs just cannot be unarchived in replays ever
so this will always spam those for something that WILL never work in kart
maybe if i decide to fix this for 32p or smth those become useful again
well it was never really disabled, but like this we can atleast change its volume lel
menu entry is still disabled, i dont think theres a single map with midi music, so this would just clutter the menu
based on work in srb2 from sphere
this gets rid of all the duplicated midi stuff
since we dont really have a whole midi soundtrack like srb2, S_GetMusicLumpNum will always prefer non midi music
this is really hacky, but M_QuitReplayHut will be skipped if we change maps, connect to a server or basically anything in that manner from within a replay that we started from the replayhut
which can lead to crashes or the replayhut to become nonfunctional
note, like this demolist is not freed, but that shouldnt matter much since it will be freed anyways the moment you open the replayhut again
use new doom-legacies PointInSeg and add a selfref check to CutOutSubsecPoly
(somewhat related, but it appears this whole file is able to mess with the actual sector planes outside of rendering, this is not really good since it may actually lead to some super hard to debug desynchs)
mostly just get rid of debug bloat that isnt even used
adding some branching hints for the I_errors (never seen any one of them happen tbh lel)
and remove some redundant checks
prob not the best way to handle this, but its the simplest
the console should always be openable without issues unless during wipes, since in some cases you end up having to kill the game to do anything
this checked the distance to every single waypoint on the map always and unconditionally, but we dont need the distance unconditionally so only check if we need to
+5fps in techbatics hadal classic timedemo
gets rid of a bunch of duplicated splitscreen shit
unused srb2 stuff
commented out stuff aswell
we dont need any of this
this is def still far from tidy and itll never be like this
apparently this makes cross compile commit sudoku, need to test this on actual windoze and see if this breaks anything since idk how this file even works
thx nep for the tip!
use it for camera, viewpoint, some precip and sound stuff and (visual) banana slope calc
after profiling it a bit, this may be 2-4x faster in most cases
This fixes slightly raised fofs drawing on top of sprites that should be in
front of them. Previously would check that the bottom of the object was above
the plane. Now also uses sprite offsets like the fof seg sorting does.
software slopes finally are sane........
fixes certain maps like stardust speedway looking like complete butt
need to test ogl, not sure if theres any real change there
Note: need to check if we gotta readd portalcullsector for ogl portals, technically this is alot faster and fixes the occasional portal disappearing, but may introduce occasional visual bugs
move screens array to "vid" struct
remove a bunch of unused stuff
this speeds up 4 player splitscreen ever so slighty
mostly just alot cleaner than the mess it was before
+ some refactoring and renaming
- removed some unused and redundant variables
- renamed some variables
turns out the lua votescreens always used the animated votescreen drawer, so i renamed it to lua votescreen drawer
it will instead always take the players mobj color, this makes it indirectly support things like acrobatics and the colourized banana snipe
also just makes it a value for cv_gamepadled instead of its own cvar
attempts to first fill the screen horizontally, if the screen is not filled vertically like that, it will then change the scaling to fill the screen vertically
like this effectively every votebg fills up the screen and accomidates most bgs that added padding for the weird vanilla behaviour
TODO: make the behaviour switchable
also some slight cleanup
currently this scales vertically to fill out the screen vertically
not sure if horizontally would be preferred, but thatd most likely cut off alot of parts from some votebgs
"driftonly" will tone the lines completely instead of alternating between blue and driftcharge
"normal" will completely colourize speedlines in the player colour
"addskins" is an incredibly ambigous name since its main purpose was to add skins LOCALLY
just prints a notice for now since there may be ppl that still use it
this is kinda horrid, but essentially, the number at the start of replay names is actually the time when the replay was recorded, so i can extract that and convert it to a readable format
this probably can be done alot cleaner lmao
below 640x400 the highres portraits become an absolute mess so itll now fallback to the lowres portraits
the statdisplay name text also became completely unreadable so itll use V_DrawThinString instead on low resolutions
before we unconditionally sent PT_WILLRESENDGAMESTATE to every connected node that didnt desynch before, in a big lobby this could mean having to send out alot of reliable packets to potentially clients that couldnt use it anyways, like this we just check if a client is saturn, which gets set the moment a saturn client v7.1 and onwards joins (it sends a special packet to the server during connect)
this makes sure we only even attempt the new resynch system with clients WE KNOW can use it anyways
this is backwards compatible until v7.1, v7 when this was introduced did not send the special packet on join and relied on the willreceivegamestate packet, so they wont benefit from the better resynching anymore
its not used for software renderer anymore and before you had to restart the game to be able to see a change in gl
8bits and 24bits options have been removed since they had no effect
and it also allowed me to unglobal things
thx srb2!
sadly we cannot really make use of ipv6 since vanilla clients cant really handle stuff well ontop of the server browser not supporting them anyways, sad!
its probably better to just disable ipv6 compile completely
however this also has minor cleanups and bugfixes for ipv4 too (server browser now should work proper if you rerfresh it often and then close and open it again etc)
instead of copieng the target mobjs rotation we just use its standingslope instead, this means shadows properly rotate according to which slope theire on
should make them visually more cohesive if a player or other mobj is rotated midair
too many ppl accidentally press right shift and end up putting things they didnt intend into their autoload file
which sometimes caused alot of issues in online play
makes things slightly cleaner and we can apply sloperoll dist to everything
should probably save some time esp with the trailing item z calc
+ P_MobjPitchAndRoll should be able to be called always since it also does stuff seperate from sloperoll
this cvar is meant to be only the toggle for the player slope rotation, however, spriterotation should still be usable in any case with this disabled. the global toggle "cv_spriteroll" has been removed
Regular blua does something similar to that, and it changes how large
numeric literals are parsed. It's very rare for those to be used but can
still in theory cause synch issues between blua and bluajit clients
- Sloperotation was weird, it now uses what we calculate in K_RollMobjsBySlopes
- in general uses srb2s newer system
- alot of cleanup of pointless variables
- sprinfo pivots should now work
- removed roillmodel since it was smth weird and broke rollangle
apparently, if the client doesent receive an ack back which may happen due to duplicate packets/bad net conditions, it may spam resend the packet until its netxcmd buffer is full and locks up
if someone doesent provide a widescreen patch it now falls back to the replaced non widescreen one and vice versa instead of just falling back to what vanilla provides
how it was before, the game just fallback to the vanila widescreen patch if there was no animated widescreen bg provided, just fall back to the non widescreen anim patch instead if it exists
when serverplayer has mindelay active
this was supposed to show mindelay for serverplayers but that doesent work :chaosleep: so just do not mess with it
- now theres realoffsets aswell
- allows better control of changing things per lua and still do funky stuff in hardcode without conflicts
- spritescales and offsets now get reset centralised before any thinkers run
so you can record attack and it will also keep saving to statistics
also added a few things it now keeps track of
TODO: unfuck the statistics page and add a 2nd one perhaps? due to space reasons
menucode is hell
if there is no patch for it
its kinda dumb, since technically would allow to not load all of em
but im lazy and dont wanna change possiblevalues around
- gamepads now aim like they used to and at same speed as keyboard
- aim reset has been changed so it resets automatically, but also can be manually reset with centerview
- aiming is locked during cam reset
- now not changable over console anymore, bind only!
- it doesent save anymore so its always disabled at game start
- moving while in spec state will disable director when active so stand still
- disable it in splitscreen completely
- only adjust view when toggling it on
keeps intended behaviour since we now dont need to worry about player controls anymore
but keeps the rebindable buttons incase someone wants to do a crazy control setup for some reason
- also dont let water and heat be applied on top of each other since it does not look good (water postimg takes priority over heat)
- also save a little time in opengl splitscreen since it does not support heat or wöter effects
ok so, for whatever dumb reason, spectatormovement will desynch at random, even on localhost.
with this we just literally fucking ignore almost every button input locally and just wont move our spectator player at all.
but since we are indeed still runiing specatotr movement code, and this is localcmd shit, the server just thinks we dont want to move and thus is "synchsave".
sadly this does not fix desynchs from vanilla players
the only code we keep is for button inputs that do certain actions like "item" so we can still join from spec with it and other crap
cause kart weird, and we cant remove the spec movement due to synch reasons
and letting the cam move instantly instead of waiting, may put you in a weird cam position
Zzz... somehow overlooked that it already gets a fof sector passed
also adds another condition since we dont need to check anything with 255 brightness
- global function that updates variables with current display resolution
-smol boolean function that quickly checks if the game res matches the desktop res
- i_downsample has been simplyfied a bit
apparently, if the client doesent receive an ack back which may happen due to duplicate packets/bad net conditions, it may spam resend the packet until its netxcmd buffer is full and locks up
not quite sure why it made stuff die so much but uhhh
instead i just check in the cube initialistion function instead and only let it build when needed to not change how the game looks with raised gamma values
- Use Z_Malloc to allocate demobuffer
- Use Z_Free to free demobuffer
- Make functions for freeing and resseting demobuffer
- Always reset demobuffer when not saving
completely forgor in kart and srb2.1 cmd.angleturn needs to be bitshifted to accomidate localangle
using it again is better, since player mobj angle is not always suitable for localangle and may slightly mismatch where a player is steering
- make software and ogl use same variable names
- let papersprites also roll in ogl not just software
- throw pitchnroll calc into a function to reduce code dupe
- save some calcs when having sliptide roll disabled
- fix software not calculating camang when just player roll is enabled (did that ever work right before? oops)
- determine early if the sprite is supposed to rotate, and only if it really does, run the rotation stuff
its only used for 2 rendering functions, so being potentially inaccurate is not that dangerous and the speedup in some instances might be worth the tradeoff
- Increase MINZ from 4 fracunits to 16
- R_StoreWallRange: do not render textures with holes
- fix off-by-one error in R_ProjectSprite
- Avoid rendering unused left/right edges of screen while rolling
- Clamp patch column post drawing bounds
- Vissprites: set dc.texheight
- Add null check for column in R_DrawMaskedColumn
we dont need to return everywhere but instead stuff can be mostly just set to 0
this also somewhat ensures stuff works after toggling without having to restart the game or map
keep sending PT_WILLRESENDGAMESTATE packets to everyone for now
saturnpak will still mark the right clients so they will use the right consistency check without having to desynch first
before the server always assumed every client cant receive the gamestate using the vanilla consistency check for everyone.
aswell as before the first resynch it tried to send the gamestate resend packets to everyone
- basic keepmusic implementation (currently checks for if the song changes instead of the map, idk if i keep this, since this allows certain maps to change the music on start, ex abstract avenue or wandering balls)
- Toggle to ignore any kind of music change during the level (includes intermission music, depends on how custom intermission music works)
-toggle to start map music instantly on levelload and skip the intro fanfare (also skips any linedef executed sound so some map intros dont interfere with this)
you can still toggle it in replays no issues
but you mostly want to watch yourself or a certain person during replays, so having to manually toggle it off always is weird
- dont reset cameras during gamestate resynch
- dont reinit director during gamesate resynch
- dont reset view interpolators aswell
- dont reset localaiming aswell
should make resynching less jarring visually hopefully
-Add new Saturn Hud options menu to declutter normal saturn options
- If in any of the hud options the game will force display the kart hud and disable the fade background
- i hate m_menu
music_resync_powerups_only literally didnt do shit lol
removed some other unused crap
changed some conditions to better check for stuff
etc idk
i just rather remove this whole thing at this point but oh well
makes this whole ordeal alot less hacky tbh
player color always gets updated if it changes
still allows for directly setting led color elsewhere by using G_SetPlayerGamepadIndicatorColor directly
hoping crap doesent cost any perf but honestly shouldnt
message(FATAL_ERROR"In-source builds will bring you a world of pain. Please make a separate directory to invoke CMake from.")
endif()
# DO NOT CHANGE THIS SRB2 STRING! Some variable names depend on this string.
# Version change is fine.
project(SRB2
VERSION1.6
LANGUAGESCCXX)
set(CMAKE_CXX_STANDARD17)
set(CMAKE_CXX_STANDARD_REQUIREDON)
#set(CMAKE_CXX_EXTENSIONS OFF) # optional but recommended: disables GNU extensions, forces pure ISO C++
set(CMAKE_CXX_EXTENSIONSON)
set(CMAKE_C_EXTENSIONSON)
##### PACKAGE CONFIGURATION #####
set(SRB2_CPACK_GENERATOR""CACHESTRING"Generator to use for making a package. E.g., ZIP, TGZ, DragNDrop (OSX only). Leave blank for default generator.")
if("${SRB2_CPACK_GENERATOR}"STREQUAL"")
if("${CMAKE_SYSTEM_NAME}"MATCHES"Windows")
set(SRB2_CPACK_GENERATOR"ZIP")
elseif("${CMAKE_SYSTEM_NAME}"MATCHES"Linux")
set(SRB2_CPACK_GENERATOR"TGZ")
elseif("${CMAKE_SYSTEM_NAME}"MATCHES"Darwin")
set(SRB2_CPACK_GENERATOR"TGZ")
endif()
endif()
set(CPACK_GENERATOR${SRB2_CPACK_GENERATOR})
set(CPACK_PACKAGE_DESCRIPTION_SUMMARY"Sonic Robo Blast 2 Kart Saturn"CACHESTRING"Program name for display purposes")
set(CPACK_PACKAGE_VENDOR"Kart Krew"CACHESTRING"Vendor name for display purposes")
@@ -21,14 +21,16 @@ We also have a Flatpak available on [Flathub](https://flathub.org/en/apps/org.sr
## Compiling
See [SRB2 Wiki/Source code compiling](http://wiki.srb2.org/wiki/Source_code_compiling). The compiling process for SRB2Kart is largely identical to SRB2.
Visual C++ (MSVC) is unsupported
Currently only the Makefile build system with GCC or Clang compiler is supported.
For Windows only the Makefile build system with GCC or Clang compiler is supported.
Visual C++ (MSVC) is unsupported.
64-bit Windows builds are supported and recommended over 32-bit builds, they will build automatically when using the MSYS2 MinGW 64-bit executable (requires the mingw-w64-x86_64-gcc package), no extra flags needed!
The specific DLLs can be found under /libs/dll-binaries/(i686 for 32bit/x86_64 for 64-bit)/ or in the Release packages
MacOS and Linux can be build with CMake, but it is recommended to use the Makefile for Linux over CMake
Alternatively the [srb2bld](https://github.com/Bijman/srb2bld) script by Bijman can be used aswell!
* Added support for 2 bits-per-pixel indexed surface formats
* Added the function SDL_GameControllerGetSteamHandle() to get the Steam API handle for a controller, if available
* Added the event SDL_CONTROLLERSTEAMHANDLEUPDATED which is sent when the Steam API handle for a controller changes. This could also change the name, VID, and PID of the controller.
* Added the environment variable SDL_LOGGING to control default log output
macOS:
* Added the hint SDL_HINT_JOYSTICK_IOKIT to control whether the IOKit controller driver should be used
* Added the hint SDL_HINT_JOYSTICK_MFI to control whether the GCController controller driver should be used
* Added the hint SDL_HINT_RENDER_METAL_PREFER_LOW_POWER_DEVICE to choose whether high or low power GPU should be used for rendering, in the case where there are multiple GPUs available
- [Following the style guide](#following-the-style-guide)
- [Running the tests](#running-the-tests)
- [Opening a pull request](#opening-a-pull-request)
- [Contributing to the documentation](#contributing-to-the-documentation)
- [Editing a function documentation](#editing-a-function-documentation)
- [Editing the wiki](#editing-the-wiki)
## Filing a GitHub issue
### Reporting a bug
If you think you have found a bug and would like to report it, here are the steps you should take:
- Before opening a new issue, ensure your bug has not already been reported on the [GitHub Issues page](https://github.com/libsdl-org/SDL/issues).
- On the issue tracker, click on [New Issue](https://github.com/libsdl-org/SDL/issues/new).
- Include details about your environment, such as your Operating System and SDL version.
- If possible, provide a small example that reproduces your bug.
### Suggesting enhancements
If you want to suggest changes for the project, here are the steps you should take:
- Check if the suggestion has already been made on:
- the [issue tracker](https://github.com/libsdl-org/SDL/issues);
- the [discourse forum](https://discourse.libsdl.org/);
- or if a [pull request](https://github.com/libsdl-org/SDL/pulls) already exists.
- On the issue tracker, click on [New Issue](https://github.com/libsdl-org/SDL/issues/new).
- Describe what change you would like to happen.
## Contributing code
This section will cover how the process of forking the project, making a change and opening a pull request.
### Forking the project
The first step consists in making a fork of the project, this is only necessary for the first contribution.
Head over to https://github.com/libsdl-org/SDL and click on the `Fork` button in the top right corner of your screen, you may leave the fields unchanged and click `Create Fork`.
You will be redirected to your fork of the repository, click the green `Code` button and copy the git clone link.
If you had already forked the repository, you may update it from the web page using the `Fetch upstream` button.
### Following the style guide
Code formatting is done using a custom `.clang-format` file, you can learn more about how to run it [here](https://clang.llvm.org/docs/ClangFormat.html).
Some legacy code may not be formatted, as such avoid formatting the whole file at once and only format around your changes.
For your commit message to be properly displayed on GitHub, it should contain:
- A short description of the commit of 50 characters or less on the first line.
- If necessary, add a blank line followed by a long description, each line should be 72 characters or less.
For example:
```
Fix crash in SDL_FooBar.
This addresses the issue #123456 by making sure Foo was successful
before calling Bar.
```
### Running the tests
Tests allow you to verify if your changes did not break any behaviour, here are the steps to follow:
- Before pushing, run the `testautomation` suite on your machine, there should be no more failing tests after your change than before.
- After pushing to your fork, Continuous Integration (GitHub Actions) will ensure compilation and tests still pass on other systems.
### Opening a pull request
- Head over to your fork's GitHub page.
- Click on the `Contribute` button and `Open Pull Request`.
- Fill out the pull request template.
- If any changes are requested, you can add new commits to your fork and they will be automatically added to the pull request.
## Contributing to the documentation
### Editing a function documentation
The wiki documentation for API functions is synchronised from the headers' doxygen comments. As such, all modifications to syntax; function parameters; return value; version; related functions should be done in the header directly.
### Editing the wiki
Other changes to the wiki should done directly from https://wiki.libsdl.org/
# Contributing to SDL
We appreciate your interest in contributing to SDL, this document will describe how to report bugs, contribute code or ideas or edit documentation.
- [Following the style guide](#following-the-style-guide)
- [Running the tests](#running-the-tests)
- [Opening a pull request](#opening-a-pull-request)
- [Contributing to the documentation](#contributing-to-the-documentation)
- [Editing a function documentation](#editing-a-function-documentation)
- [Editing the wiki](#editing-the-wiki)
## Filing a GitHub issue
### Reporting a bug
If you think you have found a bug and would like to report it, here are the steps you should take:
- Before opening a new issue, ensure your bug has not already been reported on the [GitHub Issues page](https://github.com/libsdl-org/SDL/issues).
- On the issue tracker, click on [New Issue](https://github.com/libsdl-org/SDL/issues/new).
- Include details about your environment, such as your Operating System and SDL version.
- If possible, provide a small example that reproduces your bug.
### Suggesting enhancements
If you want to suggest changes for the project, here are the steps you should take:
- Check if the suggestion has already been made on:
- the [issue tracker](https://github.com/libsdl-org/SDL/issues);
- the [discourse forum](https://discourse.libsdl.org/);
- or if a [pull request](https://github.com/libsdl-org/SDL/pulls) already exists.
- On the issue tracker, click on [New Issue](https://github.com/libsdl-org/SDL/issues/new).
- Describe what change you would like to happen.
## Contributing code
This section will cover how the process of forking the project, making a change and opening a pull request.
### Forking the project
The first step consists in making a fork of the project, this is only necessary for the first contribution.
Head over to https://github.com/libsdl-org/SDL and click on the `Fork` button in the top right corner of your screen, you may leave the fields unchanged and click `Create Fork`.
You will be redirected to your fork of the repository, click the green `Code` button and copy the git clone link.
If you had already forked the repository, you may update it from the web page using the `Fetch upstream` button.
### Following the style guide
Code formatting is done using a custom `.clang-format` file, you can learn more about how to run it [here](https://clang.llvm.org/docs/ClangFormat.html).
Some legacy code may not be formatted, as such avoid formatting the whole file at once and only format around your changes.
For your commit message to be properly displayed on GitHub, it should contain:
- A short description of the commit of 50 characters or less on the first line.
- If necessary, add a blank line followed by a long description, each line should be 72 characters or less.
For example:
```
Fix crash in SDL_FooBar.
This addresses the issue #123456 by making sure Foo was successful
before calling Bar.
```
### Running the tests
Tests allow you to verify if your changes did not break any behaviour, here are the steps to follow:
- Before pushing, run the `testautomation` suite on your machine, there should be no more failing tests after your change than before.
- After pushing to your fork, Continuous Integration (GitHub Actions) will ensure compilation and tests still pass on other systems.
### Opening a pull request
- Head over to your fork's GitHub page.
- Click on the `Contribute` button and `Open Pull Request`.
- Fill out the pull request template.
- If any changes are requested, you can add new commits to your fork and they will be automatically added to the pull request.
## Contributing to the documentation
### Editing a function documentation
The wiki documentation for API functions is synchronised from the headers' doxygen comments. As such, all modifications to syntax; function parameters; return value; version; related functions should be done in the header directly.
### Editing the wiki
Other changes to the wiki should done directly from https://wiki.libsdl.org/
One limitation of this script is that all sources provided will be aggregated into
a single directory, thus all your source files should have a unique name.
Once the project is complete the script will tell you where the debug APK is located.
If you want to create a signed release APK, you can use the project created by this
utility to generate it.
Finally, a word of caution: re running androidbuild.sh wipes any changes you may have
done in the build directory for the app!
For more complex projects, follow these instructions:
1. Get the source code for SDL and copy the 'android-project' directory located at SDL/android-project to a suitable location. Also make sure to rename it to your project name (In these examples: YOURPROJECT).
(The 'android-project' directory can basically be seen as a sort of starting point for the android-port of your project. It contains the glue code between the Android Java 'frontend' and the SDL code 'backend'. It also contains some standard behaviour, like how events should be handled, which you will be able to change.)
2. Move or [symlink](https://en.wikipedia.org/wiki/Symbolic_link) the SDL directory into the "YOURPROJECT/app/jni" directory
(This is needed as the source of SDL has to be compiled by the Android compiler)
3. Edit "YOURPROJECT/app/jni/src/Android.mk" to include your source files.
(They should be separated by spaces after the "LOCAL_SRC_FILES := " declaration)
4a. If you want to use Android Studio, simply open your 'YOURPROJECT' directory and start building.
4b. If you want to build manually, run './gradlew installDebug' in the project directory. This compiles the .java, creates an .apk with the native code embedded, and installs it on any connected Android device
If you already have a project that uses CMake, the instructions change somewhat:
1. Do points 1 and 2 from the instruction above.
2. Edit "YOURPROJECT/app/build.gradle" to comment out or remove sections containing ndk-build
and uncomment the cmake sections. Add arguments to the CMake invocation as needed.
3. Edit "YOURPROJECT/app/jni/CMakeLists.txt" to include your project (it defaults to
adding the "src" subdirectory). Note that you'll have SDL2, SDL2main and SDL2-static
as targets in your project, so you should have "target_link_libraries(yourgame SDL2 SDL2main)"
in your CMakeLists.txt file. Also be aware that you should use add_library() instead of
add_executable() for the target containing your "main" function.
If you wish to use Android Studio, you can skip the last step.
4. Run './gradlew installDebug' or './gradlew installRelease' in the project directory. It will build and install your .apk on any
connected Android device
Here's an explanation of the files in the Android project, so you can customize them:
android-project/app
build.gradle - build info including the application version and SDK
src/main/AndroidManifest.xml - package manifest. Among others, it contains the class name of the main Activity and the package name of the application.
jni/ - directory holding native code
jni/Application.mk - Application JNI settings, including target platform and STL library
jni/Android.mk - Android makefile that can call recursively the Android.mk files in all subdirectories
jni/CMakeLists.txt - Top-level CMake project that adds SDL as a subproject
jni/SDL/ - (symlink to) directory holding the SDL library files
jni/SDL/Android.mk - Android makefile for creating the SDL shared library
jni/src/ - directory holding your C/C++ source
jni/src/Android.mk - Android makefile that you should customize to include your source code and any library references
jni/src/CMakeLists.txt - CMake file that you may customize to include your source code and any library references
src/main/assets/ - directory holding asset files for your application
src/main/res/ - directory holding resources for your application
src/main/res/mipmap-* - directories holding icons for different phone hardware
src/main/res/values/strings.xml - strings used in your application, including the application name
src/main/java/org/libsdl/app/SDLActivity.java - the Java class handling the initialization and binding to SDL. Be very careful changing this, as the SDL library relies on this implementation. You should instead subclass this for your application.
One limitation of this script is that all sources provided will be aggregated into
a single directory, thus all your source files should have a unique name.
Once the project is complete the script will tell you where the debug APK is located.
If you want to create a signed release APK, you can use the project created by this
utility to generate it.
Finally, a word of caution: re running androidbuild.sh wipes any changes you may have
done in the build directory for the app!
For more complex projects, follow these instructions:
1. Get the source code for SDL and copy the 'android-project' directory located at SDL/android-project to a suitable location. Also make sure to rename it to your project name (In these examples: YOURPROJECT).
(The 'android-project' directory can basically be seen as a sort of starting point for the android-port of your project. It contains the glue code between the Android Java 'frontend' and the SDL code 'backend'. It also contains some standard behaviour, like how events should be handled, which you will be able to change.)
2. Move or [symlink](https://en.wikipedia.org/wiki/Symbolic_link) the SDL directory into the "YOURPROJECT/app/jni" directory
(This is needed as the source of SDL has to be compiled by the Android compiler)
3. Edit "YOURPROJECT/app/jni/src/Android.mk" to include your source files.
(They should be separated by spaces after the "LOCAL_SRC_FILES := " declaration)
4a. If you want to use Android Studio, simply open your 'YOURPROJECT' directory and start building.
4b. If you want to build manually, run './gradlew installDebug' in the project directory. This compiles the .java, creates an .apk with the native code embedded, and installs it on any connected Android device
If you already have a project that uses CMake, the instructions change somewhat:
1. Do points 1 and 2 from the instruction above.
2. Edit "YOURPROJECT/app/build.gradle" to comment out or remove sections containing ndk-build
and uncomment the cmake sections. Add arguments to the CMake invocation as needed.
3. Edit "YOURPROJECT/app/jni/CMakeLists.txt" to include your project (it defaults to
adding the "src" subdirectory). Note that you'll have SDL2, SDL2main and SDL2-static
as targets in your project, so you should have "target_link_libraries(yourgame SDL2 SDL2main)"
in your CMakeLists.txt file. Also be aware that you should use add_library() instead of
add_executable() for the target containing your "main" function.
If you wish to use Android Studio, you can skip the last step.
4. Run './gradlew installDebug' or './gradlew installRelease' in the project directory. It will build and install your .apk on any
connected Android device
Here's an explanation of the files in the Android project, so you can customize them:
android-project/app
build.gradle - build info including the application version and SDK
src/main/AndroidManifest.xml - package manifest. Among others, it contains the class name of the main Activity and the package name of the application.
jni/ - directory holding native code
jni/Application.mk - Application JNI settings, including target platform and STL library
jni/Android.mk - Android makefile that can call recursively the Android.mk files in all subdirectories
jni/CMakeLists.txt - Top-level CMake project that adds SDL as a subproject
jni/SDL/ - (symlink to) directory holding the SDL library files
jni/SDL/Android.mk - Android makefile for creating the SDL shared library
jni/src/ - directory holding your C/C++ source
jni/src/Android.mk - Android makefile that you should customize to include your source code and any library references
jni/src/CMakeLists.txt - CMake file that you may customize to include your source code and any library references
src/main/assets/ - directory holding asset files for your application
src/main/res/ - directory holding resources for your application
src/main/res/mipmap-* - directories holding icons for different phone hardware
src/main/res/values/strings.xml - strings used in your application, including the application name
src/main/java/org/libsdl/app/SDLActivity.java - the Java class handling the initialization and binding to SDL. Be very careful changing this, as the SDL library relies on this implementation. You should instead subclass this for your application.
# Link to the actual SDL2 library. SDL2::SDL2 is the shared SDL library, SDL2::SDL2-static is the static SDL libarary.
target_link_libraries(mygamePRIVATESDL2::SDL2)
```
### A system SDL library
For CMake to find SDL, it must be installed in [a default location CMake is looking for](https://cmake.org/cmake/help/latest/command/find_package.html#config-mode-search-procedure).
The following components are available, to be used as an argument of `find_package`.
# Link to the actual SDL2 library. SDL2::SDL2 is the shared SDL library, SDL2::SDL2-static is the static SDL libarary.
target_link_libraries(mygamePRIVATESDL2::SDL2)
```
### A system SDL library
For CMake to find SDL, it must be installed in [a default location CMake is looking for](https://cmake.org/cmake/help/latest/command/find_package.html#config-mode-search-procedure).
The following components are available, to be used as an argument of `find_package`.
This port allows SDL applications to run via Microsoft's Game Development Kit (GDK).
Windows (GDK) and Xbox One/Xbox Series (GDKX) are both supported and all the required code is included in this public SDL release. However, only licensed Xbox developers have access to the GDKX libraries which will allow you to build the Xbox targets.
Requirements
------------
* Microsoft Visual Studio 2022 (in theory, it should also work in 2017 or 2019, but this has not been tested)
* Microsoft GDK June 2022 or newer (public release [here](https://github.com/microsoft/GDK/releases/tag/June_2022))
*For Xbox, you will need the corresponding GDKX version (licensed developers only)
* To publish a package or successfully authenticate a user, you will need to create an app id/configure services in Partner Center. However, for local testing purposes (without authenticating on Xbox Live), the identifiers used by the GDK test programs in the included solution will work.
Windows GDK Status
------
The Windows GDK port supports the full set of Win32 APIs, renderers, controllers, input devices, etc., as the normal Windows x64 build of SDL.
*Additionally, the GDK port adds the following:
*Compile-time platform detection for SDL programs. The `__GDK__` is `#define`d on every GDK platform, and the `__WINGDK__` is `#define`d on Windows GDK, specifically. (This distinction exists because other GDK platforms support a smaller subset of functionality. This allows you to mark code for "any" GDK separate from Windows GDK.)
*GDK-specific setup:
*Initializing/uninitializing the game runtime, and initializing Xbox Live services
* Creating a global task queue and setting it as the default for the process. When running any async operations, passing in `NULL` as the task queue will make the task get added to the global task queue.
*An implementation on `WinMain` that performs the above GDK setup (you should link against SDL2main.lib, as in Windows x64). If you are unable to do this, you can instead manually call `SDL_GDKRunApp` from your entry point, passing in your `SDL_main` function and `NULL` as the parameters.
*Global task queue callbacks are dispatched during `SDL_PumpEvents` (which is also called internally if using `SDL_PollEvent`).
* You can get the handle of the global task queue through `SDL_GDKGetTaskQueue`, if needed. When done with the queue, be sure to use `XTaskQueueCloseHandle` to decrement the reference count (otherwise it will cause a resource leak).
*Single-player games have some additional features available:
* Call `SDL_GDKGetDefaultUser` to get the default XUserHandle pointer.
*`SDL_GetPrefPath` still works, but only for single-player titles.
These functions mostly wrap around async APIs, and thus should be treated as synchronous alternatives. Also note that the single-player functions return on any OS errors, so be sure to validate the return values!
*What doesn't work:
*Compilation with anything other than through the included Visual C++ solution file
## VisualC-GDK Solution
The included `VisualC-GDK/SDL.sln` solution includes the following targets for the Gaming.Desktop.x64 configuration:
* SDL2 (DLL) - This is the typical SDL2.dll, but for Gaming.Desktop.x64.
* SDL2main (lib) - This contains a drop-in implementation of `WinMain` that is used as the entry point for GDK programs.
* tests/testgamecontroller - Standard SDL test program demonstrating controller functionality.
* tests/testgdk - GDK-specific test program that demonstrates using the global task queue to login a user into Xbox Live.
*NOTE*: As of the June 2022 GDK, you cannot test user logins without a valid Title ID and MSAAppId. You will need to manually change the identifiers in the `MicrosoftGame.config` to your valid IDs from Partner Center if you wish to test this.
* tests/testsprite2 - Standard SDL test program demonstrating sprite drawing functionality.
If you set one of the test programs as a startup project, you can run it directly from Visual Studio.
Windows GDK Setup, Detailed Steps
---------------------
These steps assume you already have a game using SDL that runs on Windows x64 along with a corresponding Visual Studio solution file for the x64 version. If you don't have this, it's easiest to use one of the test program vcxproj files in the `VisualC-GDK` directory as a starting point, though you will still need to do most of the steps below.
### 1. Add a Gaming.Desktop.x64 Configuration ###
In your game's existing Visual Studio Solution, go to Build > Configuration Manager. From the "Active solution platform" drop-down select "New...". From the drop-down list, select Gaming.Desktop.x64 and copy the settings from the x64 configuration.
### 2. Build SDL2 and SDL2main for GDK ###
Open `VisualC-GDK/SDL.sln` in Visual Studio, you need to build the SDL2 and SDL2main targets for the Gaming.Desktop.x64 platform (Release is recommended). You will need to copy/keep track of the `SDL2.dll`, `XCurl.dll` (which is output by Gaming.Desktop.x64), `SDL2.lib`, and `SDL2main.lib` output files for your game project.
*Alternatively*, you could setup your solution file to instead reference the SDL2/SDL2main project file targets from the SDL source, and add those projects as a dependency. This would mean that SDL2 and SDL2main would both be built when your game is built.
### 3. Configuring Project Settings ###
While the Gaming.Desktop.x64 configuration sets most of the required settings, there are some additional items to configure for your game project under the Gaming.Desktop.x64 Configuration:
* Under C/C++ > General > Additional Include Directories, make sure the `SDL/include` path is referenced
* Under Linker > General > Additional Library Directories, make sure to reference the path where the newly-built SDL2.lib and SDL2main.lib are
* Under Linker > Input > Additional Dependencies, you need the following:
* Note that in general, the GDK libraries depend on the MSVC C/C++ runtime, so there is no way to remove this dependency from a GDK program that links against GDK.
### 4. Setting up SDL_main ###
Rather than using your own implementation of `WinMain`, it's recommended that you instead `#include "SDL_main.h"` and declare a standard main function. If you are unable to do this, you can instead manually call `SDL_GDKRunApp` from your entry point, passing in your `SDL_main` function and `NULL` as the parameters.
### 5. Required DLLs ###
The game will not launch in the debugger unless required DLLs are included in the directory that contains the game's .exe file. You need to make sure that the following files are copied into the directory:
You can either copy these in a post-build step, or you can add the dlls into the project and set its Configuration Properties > General > Item type to "Copy file," which will also copy them into the output directory.
### 6. Setting up MicrosoftGame.config ###
You can copy `VisualC-GDK/tests/testgdk/MicrosoftGame.config` and use that as a starting point in your project. Minimally, you will want to change the Executable Name attribute, the DefaultDisplayName, and the Description.
This file must be copied into the same directory as the game's .exe file. As with the DLLs, you can either use a post-build step or the "Copy file" item type.
For basic testing, you do not need to change anything else in `MicrosoftGame.config`. However, if you want to test any Xbox Live services (such as logging in users) _or_ publish a package, you will need to setup a Game app on Partner Center.
Then, you need to set the following values to the values from Partner Center:
* Identity tag - Name and Publisher attributes
* TitleId
* MSAAppId
### 7. Adding Required Logos
Several logo PNG files are required to be able to launch the game, even from the debugger. You can use the sample logos provided in `VisualC-GDK/logos`. As with the other files, they must be copied into the same directory as the game's .exe file.
### 8. Copying any Data Files ###
When debugging GDK games, there is no way to specify a working directory. Therefore, any required game data must also be copied into the output directory, likely in a post-build step.
### 9. Build and Run from Visual Studio ###
At this point, you should be able to build and run your game from the Visual Studio Debugger. If you get any linker errors, make sure you double-check that you referenced all the required libs.
If you are testing Xbox Live functionality, it's likely you will need to change to the Sandbox for your title. To do this:
1. Run "Desktop VS 2022 Gaming Command Prompt" from the Start Menu
2. Switch the sandbox name with:
`XblPCSandbox SANDBOX.#`
3. (To switch back to the retail sandbox):
`XblPCSandbox RETAIL`
### 10. Packaging and Installing Locally
You can use one of the test program's `PackageLayout.xml` as a starting point. Minimally, you will need to change the exe to the correct name and also reference any required game data. As with the other data files, it's easiest if you have this copy to the output directory, although it's not a requirement as you can specify relative paths to files.
To create the package:
1. Run "Desktop VS 2022 Gaming Command Prompt" from the Start Menu
2.`cd` to the directory containing the `PackageLayout.xml` with the correct paths (if you use the local path as in the sample package layout, this would be from your .exe output directory)
3.`mkdir Package` to create an output directory
4. To package the file into the `Package` directory, use:
6. Once the package is installed, you can run it from the start menu.
7. As with when running from Visual Studio, if you need to test any Xbox Live functionality you must switch to the correct sandbox.
Xbox GDKX Setup
---------------------
In general, the same process in the Windows GDK instructions work. There are just a few additional notes:
* For Xbox One consoles, use the Gaming.Xbox.XboxOne.x64 target
* For Xbox Series consoles, use the Gaming.Xbox.Scarlett.x64 target
* The Xbox One target sets the `__XBOXONE__` define and the Xbox Series target sets the `__XBOXSERIES__` define
* You don't need to link against the Xbox.Services Thunks lib nor include that dll in your package (it doesn't exist for Xbox)
* The shader blobs for Xbox are created in a pre-build step for the Xbox targets, rather than included in the source (due to NDA and version compatability reasons)
* For some reason, if you make changes that require SDL2.dll to build, and you are running through the debugger (instead of a package), you have to rebuild your .exe target for the debugger to recognize the dll has changed and needs to be transferred to the console again
* While there are successful releases of Xbox titles using this port, it is not as extensively tested as other targets
Troubleshooting
---------------
#### Xbox Live Login does not work
As of June 2022 GDK, you must have a valid Title Id and MSAAppId in order to test Xbox Live functionality such as user login. Make sure these are set correctly in the `MicrosoftGame.config`. This means that even testgdk will not let you login without setting these properties to valid values.
Furthermore, confirm that your PC is set to the correct sandbox.
#### "The current user has already installed an unpackaged version of this app. A packaged version cannot replace this." error when installing
Prior to June 2022 GDK, running from the Visual Studio debugger would still locally register the app (and it would appear on the start menu). To fix this, you have to uninstall it (it's simplest to right click on it from the start menu to uninstall it).
GDK
=====
This port allows SDL applications to run via Microsoft's Game Development Kit (GDK).
Windows (GDK) and Xbox One/Xbox Series (GDKX) are supported. Although most of the Xbox code is included in the public SDL source code, NDA access is required for a small number of source files. If you have access to GDKX, these required Xbox files are posted on the GDK forums [here](https://forums.xboxlive.com/questions/130003/).
Requirements
------------
* Microsoft Visual Studio 2022 (in theory, it should also work in 2017 or 2019, but this has not been tested)
* Microsoft GDK June 2022 or newer (public release [here](https://github.com/microsoft/GDK/releases/tag/June_2022))
*To publish a package or successfully authenticate a user, you will need to create an app id/configure services in Partner Center. However, for local testing purposes (without authenticating on Xbox Live), the identifiers used by the GDK test programs in the included solution will work.
Windows GDK Status
------
The Windows GDK port supports the full set of Win32 APIs, renderers, controllers, input devices, etc., as the normal Windows x64 build of SDL.
* Additionally, the GDK port adds the following:
*Compile-time platform detection for SDL programs. The `__GDK__` is `#define`d on every GDK platform, and the `__WINGDK__` is `#define`d on Windows GDK, specifically. (This distinction exists because other GDK platforms support a smaller subset of functionality. This allows you to mark code for "any" GDK separate from Windows GDK.)
*GDK-specific setup:
*Initializing/uninitializing the game runtime, and initializing Xbox Live services
*Creating a global task queue and setting it as the default for the process. When running any async operations, passing in `NULL` as the task queue will make the task get added to the global task queue.
* An implementation on `WinMain` that performs the above GDK setup (you should link against SDL2main.lib, as in Windows x64). If you are unable to do this, you can instead manually call `SDL_GDKRunApp` from your entry point, passing in your `SDL_main` function and `NULL` as the parameters.
*Global task queue callbacks are dispatched during `SDL_PumpEvents` (which is also called internally if using `SDL_PollEvent`).
*You can get the handle of the global task queue through `SDL_GDKGetTaskQueue`, if needed. When done with the queue, be sure to use `XTaskQueueCloseHandle` to decrement the reference count (otherwise it will cause a resource leak).
* What doesn't work:
*Compilation with anything other than through the included Visual C++ solution file
## VisualC-GDK Solution
The included `VisualC-GDK/SDL.sln` solution includes the following targets for the Gaming.Desktop.x64 configuration:
*SDL2 (DLL) - This is the typical SDL2.dll, but for Gaming.Desktop.x64.
*SDL2main (lib) - This contains a drop-in implementation of `WinMain` that is used as the entry point for GDK programs.
* tests/testgamecontroller - Standard SDL test program demonstrating controller functionality.
* tests/testgdk - GDK-specific test program that demonstrates using the global task queue to login a user into Xbox Live.
*NOTE*: As of the June 2022 GDK, you cannot test user logins without a valid Title ID and MSAAppId. You will need to manually change the identifiers in the `MicrosoftGame.config` to your valid IDs from Partner Center if you wish to test this.
* tests/testsprite2 - Standard SDL test program demonstrating sprite drawing functionality.
If you set one of the test programs as a startup project, you can run it directly from Visual Studio.
Windows GDK Setup, Detailed Steps
---------------------
These steps assume you already have a game using SDL that runs on Windows x64 along with a corresponding Visual Studio solution file for the x64 version. If you don't have this, it's easiest to use one of the test program vcxproj files in the `VisualC-GDK` directory as a starting point, though you will still need to do most of the steps below.
### 1. Add a Gaming.Desktop.x64 Configuration ###
In your game's existing Visual Studio Solution, go to Build > Configuration Manager. From the "Active solution platform" drop-down select "New...". From the drop-down list, select Gaming.Desktop.x64 and copy the settings from the x64 configuration.
### 2. Build SDL2 and SDL2main for GDK ###
Open `VisualC-GDK/SDL.sln` in Visual Studio, you need to build the SDL2 and SDL2main targets for the Gaming.Desktop.x64 platform (Release is recommended). You will need to copy/keep track of the `SDL2.dll`, `XCurl.dll` (which is output by Gaming.Desktop.x64), `SDL2.lib`, and `SDL2main.lib` output files for your game project.
*Alternatively*, you could setup your solution file to instead reference the SDL2/SDL2main project file targets from the SDL source, and add those projects as a dependency. This would mean that SDL2 and SDL2main would both be built when your game is built.
### 3. Configuring Project Settings ###
While the Gaming.Desktop.x64 configuration sets most of the required settings, there are some additional items to configure for your game project under the Gaming.Desktop.x64 Configuration:
* Under C/C++ > General > Additional Include Directories, make sure the `SDL/include` path is referenced
* Under Linker > General > Additional Library Directories, make sure to reference the path where the newly-built SDL2.lib and SDL2main.lib are
* Under Linker > Input > Additional Dependencies, you need the following:
*Note that in general, the GDK libraries depend on the MSVC C/C++ runtime, so there is no way to remove this dependency from a GDK program that links against GDK.
### 4. Setting up SDL_main ###
Rather than using your own implementation of `WinMain`, it's recommended that you instead `#include "SDL_main.h"` and declare a standard main function. If you are unable to do this, you can instead manually call `SDL_GDKRunApp` from your entry point, passing in your `SDL_main` function and `NULL` as the parameters.
### 5. Required DLLs ###
The game will not launch in the debugger unless required DLLs are included in the directory that contains the game's .exe file. You need to make sure that the following files are copied into the directory:
You can either copy these in a post-build step, or you can add the dlls into the project and set its Configuration Properties > General > Item type to "Copy file," which will also copy them into the output directory.
### 6. Setting up MicrosoftGame.config ###
You can copy `VisualC-GDK/tests/testgdk/MicrosoftGame.config` and use that as a starting point in your project. Minimally, you will want to change the Executable Name attribute, the DefaultDisplayName, and the Description.
This file must be copied into the same directory as the game's .exe file. As with the DLLs, you can either use a post-build step or the "Copy file" item type.
For basic testing, you do not need to change anything else in `MicrosoftGame.config`. However, if you want to test any Xbox Live services (such as logging in users) _or_ publish a package, you will need to setup a Game app on Partner Center.
Then, you need to set the following values to the values from Partner Center:
* Identity tag - Name and Publisher attributes
* TitleId
* MSAAppId
### 7. Adding Required Logos
Several logo PNG files are required to be able to launch the game, even from the debugger. You can use the sample logos provided in `VisualC-GDK/logos`. As with the other files, they must be copied into the same directory as the game's .exe file.
### 8. Copying any Data Files ###
When debugging GDK games, there is no way to specify a working directory. Therefore, any required game data must also be copied into the output directory, likely in a post-build step.
### 9. Build and Run from Visual Studio ###
At this point, you should be able to build and run your game from the Visual Studio Debugger. If you get any linker errors, make sure you double-check that you referenced all the required libs.
If you are testing Xbox Live functionality, it's likely you will need to change to the Sandbox for your title. To do this:
1. Run "Desktop VS 2022 Gaming Command Prompt" from the Start Menu
2. Switch the sandbox name with:
`XblPCSandbox SANDBOX.#`
3. (To switch back to the retail sandbox):
`XblPCSandbox RETAIL`
### 10. Packaging and Installing Locally
You can use one of the test program's `PackageLayout.xml` as a starting point. Minimally, you will need to change the exe to the correct name and also reference any required game data. As with the other data files, it's easiest if you have this copy to the output directory, although it's not a requirement as you can specify relative paths to files.
To create the package:
1. Run "Desktop VS 2022 Gaming Command Prompt" from the Start Menu
2.`cd` to the directory containing the `PackageLayout.xml` with the correct paths (if you use the local path as in the sample package layout, this would be from your .exe output directory)
3.`mkdir Package` to create an output directory
4. To package the file into the `Package` directory, use:
6. Once the package is installed, you can run it from the start menu.
7. As with when running from Visual Studio, if you need to test any Xbox Live functionality you must switch to the correct sandbox.
Troubleshooting
---------------
#### Xbox Live Login does not work
As of June 2022 GDK, you must have a valid Title Id and MSAAppId in order to test Xbox Live functionality such as user login. Make sure these are set correctly in the `MicrosoftGame.config`. This means that even testgdk will not let you login without setting these properties to valid values.
Furthermore, confirm that your PC is set to the correct sandbox.
#### "The current user has already installed an unpackaged version of this app. A packaged version cannot replace this." error when installing
Prior to June 2022 GDK, running from the Visual Studio debugger would still locally register the app (and it would appear on the start menu). To fix this, you have to uninstall it (it's simplest to right click on it from the start menu to uninstall it).
SDL provides an implementation of the $1 gesture recognition system. This allows for recording, saving, loading, and performing single stroke gestures.
Gestures can be performed with any number of fingers (the centroid of the fingers must follow the path of the gesture), but the number of fingers must be constant (a finger cannot go down in the middle of a gesture). The path of a gesture is considered the path from the time when the final finger went down, to the first time any finger comes up.
Dollar gestures are assigned an Id based on a hash function. This is guaranteed to remain constant for a given gesture. There is a (small) chance that two different gestures will be assigned the same ID. In this case, simply re-recording one of the gestures should result in a different ID.
Recording:
----------
To begin recording on a touch device call:
SDL_RecordGesture(SDL_TouchID touchId), where touchId is the id of the touch device you wish to record on, or -1 to record on all connected devices.
Recording terminates as soon as a finger comes up. Recording is acknowledged by an SDL_DOLLARRECORD event.
A SDL_DOLLARRECORD event is a dgesture with the following fields:
* event.dgesture.touchId - the Id of the touch used to record the gesture.
* event.dgesture.gestureId - the unique id of the recorded gesture.
Performing:
-----------
As long as there is a dollar gesture assigned to a touch, every finger-up event will also cause an SDL_DOLLARGESTURE event with the following fields:
* event.dgesture.touchId - the Id of the touch which performed the gesture.
* event.dgesture.gestureId - the unique id of the closest gesture to the performed stroke.
* event.dgesture.error - the difference between the gesture template and the actual performed gesture. Lower error is a better match.
* event.dgesture.numFingers - the number of fingers used to draw the stroke.
Most programs will want to define an appropriate error threshold and check to be sure that the error of a gesture is not abnormally high (an indicator that no gesture was performed).
Saving:
-------
To save a template, call SDL_SaveDollarTemplate(gestureId, dst) where gestureId is the id of the gesture you want to save, and dst is an SDL_RWops pointer to the file where the gesture will be stored.
To save all currently loaded templates, call SDL_SaveAllDollarTemplates(dst) where dst is an SDL_RWops pointer to the file where the gesture will be stored.
Both functions return the number of gestures successfully saved.
Loading:
--------
To load templates from a file, call SDL_LoadDollarTemplates(touchId,src) where touchId is the id of the touch to load to (or -1 to load to all touch devices), and src is an SDL_RWops pointer to a gesture save file.
SDL_LoadDollarTemplates returns the number of templates successfully loaded.
SDL provides an implementation of the $1 gesture recognition system. This allows for recording, saving, loading, and performing single stroke gestures.
Gestures can be performed with any number of fingers (the centroid of the fingers must follow the path of the gesture), but the number of fingers must be constant (a finger cannot go down in the middle of a gesture). The path of a gesture is considered the path from the time when the final finger went down, to the first time any finger comes up.
Dollar gestures are assigned an Id based on a hash function. This is guaranteed to remain constant for a given gesture. There is a (small) chance that two different gestures will be assigned the same ID. In this case, simply re-recording one of the gestures should result in a different ID.
Recording:
----------
To begin recording on a touch device call:
SDL_RecordGesture(SDL_TouchID touchId), where touchId is the id of the touch device you wish to record on, or -1 to record on all connected devices.
Recording terminates as soon as a finger comes up. Recording is acknowledged by an SDL_DOLLARRECORD event.
A SDL_DOLLARRECORD event is a dgesture with the following fields:
* event.dgesture.touchId - the Id of the touch used to record the gesture.
* event.dgesture.gestureId - the unique id of the recorded gesture.
Performing:
-----------
As long as there is a dollar gesture assigned to a touch, every finger-up event will also cause an SDL_DOLLARGESTURE event with the following fields:
* event.dgesture.touchId - the Id of the touch which performed the gesture.
* event.dgesture.gestureId - the unique id of the closest gesture to the performed stroke.
* event.dgesture.error - the difference between the gesture template and the actual performed gesture. Lower error is a better match.
* event.dgesture.numFingers - the number of fingers used to draw the stroke.
Most programs will want to define an appropriate error threshold and check to be sure that the error of a gesture is not abnormally high (an indicator that no gesture was performed).
Saving:
-------
To save a template, call SDL_SaveDollarTemplate(gestureId, dst) where gestureId is the id of the gesture you want to save, and dst is an SDL_RWops pointer to the file where the gesture will be stored.
To save all currently loaded templates, call SDL_SaveAllDollarTemplates(dst) where dst is an SDL_RWops pointer to the file where the gesture will be stored.
Both functions return the number of gestures successfully saved.
Loading:
--------
To load templates from a file, call SDL_LoadDollarTemplates(touchId,src) where touchId is the id of the touch to load to (or -1 to load to all touch devices), and src is an SDL_RWops pointer to a gesture save file.
SDL_LoadDollarTemplates returns the number of templates successfully loaded.
1. Run Xcode and create a new project using the iOS Game template, selecting the Objective C language and Metal game technology.
2. In the main view, delete all files except for Assets and LaunchScreen
3. Right click the project in the main view, select "Add Files...", and add the SDL project, Xcode/SDL/SDL.xcodeproj
4. Select the project in the main view, go to the "Info" tab and under "Custom iOS Target Properties" remove the line "Main storyboard file base name"
5. Select the project in the main view, go to the "Build Settings" tab, select "All", and edit "Header Search Path" and drag over the SDL "Public Headers" folder from the left
6. Select the project in the main view, go to the "Build Phases" tab, select "Link Binary With Libraries", and add SDL2.framework from "Framework-iOS"
7. Select the project in the main view, go to the "General" tab, scroll down to "Frameworks, Libraries, and Embedded Content", and select "Embed & Sign" for the SDL library.
8. In the main view, expand SDL -> Library Source -> main -> uikit and drag SDL_uikit_main.c into your game files
9. Add the source files that you would normally have for an SDL program, making sure to have #include "SDL.h" at the top of the file containing your main() function.
10. Add any assets that your application needs.
11. Enjoy!
TODO: Add information regarding App Store requirements such as icons, etc.
SDL for iPhone supports polling the built in accelerometer as a joystick device. For an example on how to do this, see the accelerometer.c in the demos directory.
The main thing to note when using the accelerometer with SDL is that while the iPhone natively reports accelerometer as floating point values in units of g-force, SDL_JoystickGetAxis() reports joystick values as signed integers. Hence, in order to convert between the two, some clamping and scaling is necessary on the part of the iPhone SDL joystick driver. To convert SDL_JoystickGetAxis() reported values BACK to units of g-force, simply multiply the values by SDL_IPHONE_MAX_GFORCE / 0x7FFF.
Your SDL application for iOS uses OpenGL ES for video by default.
OpenGL ES for iOS supports several display pixel formats, such as RGBA8 and RGB565, which provide a 32 bit and 16 bit color buffer respectively. By default, the implementation uses RGB565, but you may use RGBA8 by setting each color component to 8 bits in SDL_GL_SetAttribute().
If your application doesn't use OpenGL's depth buffer, you may find significant performance improvement by setting SDL_GL_DEPTH_SIZE to 0.
Finally, if your application completely redraws the screen each frame, you may find significant performance improvement by setting the attribute SDL_GL_RETAINED_BACKING to 0.
OpenGL ES on iOS doesn't use the traditional system-framebuffer setup provided in other operating systems. Special care must be taken because of this:
- The drawable Renderbuffer must be bound to the GL_RENDERBUFFER binding point when SDL_GL_SwapWindow() is called.
- The drawable Framebuffer Object must be bound while rendering to the screen and when SDL_GL_SwapWindow() is called.
- If multisample antialiasing (MSAA) is used and glReadPixels is used on the screen, the drawable framebuffer must be resolved to the MSAA resolve framebuffer (via glBlitFramebuffer or glResolveMultisampleFramebufferAPPLE), and the MSAA resolve framebuffer must be bound to the GL_READ_FRAMEBUFFER binding point, before glReadPixels is called.
The above objects can be obtained via SDL_GetWindowWMInfo() (in SDL_syswm.h).
iOS now supports Bluetooth mice on iPad, but by default will provide the mouse input as touch. In order for SDL to see the real mouse events, you should set the key UIApplicationSupportsIndirectInputEvents to true in your Info.plist
Each application installed on iPhone resides in a sandbox which includes its own Application Home directory. Your application may not access files outside this directory.
Once your application is installed its directory tree looks like:
MySDLApp Home/
MySDLApp.app
Documents/
Library/
Preferences/
tmp/
When your SDL based iPhone application starts up, it sets the working directory to the main bundle (MySDLApp Home/MySDLApp.app), where your application resources are stored. You cannot write to this directory. Instead, I advise you to write document files to "../Documents/" and preferences to "../Library/Preferences".
More information on this subject is available here:
The SDL.xcodeproj file now includes a target to build SDL2.xcframework. An xcframework is a new (Xcode 11) uber-framework which can handle any combination of processor type and target OS platform.
In the past, iOS devices were always an ARM variant processor, and the simulator was always i386 or x86_64, and thus libraries could be combined into a single framework for both simulator and device. With the introduction of the Apple Silicon ARM-based machines, regular frameworks would collide as CPU type was no longer sufficient to differentiate the platform. So Apple created the new xcframework library package.
The xcframework target builds into a Products directory alongside the SDL.xcodeproj file, as SDL2.xcframework. This can be brought in to any iOS project and will function properly for both simulator and device, no matter their CPUs. Note that Intel Macs cannot cross-compile for Apple Silicon Macs. If you need AS compatibility, perform this build on an Apple Silicon Mac.
This target requires Xcode 11 or later. The target will simply fail to build if attempted on older Xcodes.
In addition, on Apple platforms, main() cannot be in a dynamically loaded library. This means that iOS apps which used the statically-linked libSDL2.lib and now link with the xcframwork will need to define their own main() to call SDL_UIKitRunApp(), like this:
#ifndef SDL_MAIN_HANDLED
#ifdef main
#undef main
#endif
int
main(int argc, char *argv[])
{
return SDL_UIKitRunApp(argc, argv, SDL_main);
}
#endif /* !SDL_MAIN_HANDLED */
Using an xcFramework is similar to using a regular framework. However, issues have been seen with the build system not seeing the headers in the xcFramework. To remedy this, add the path to the xcFramework in your app's target ==> Build Settings ==> Framework Search Paths and mark it recursive (this is critical). Also critical is to remove "*.framework" from Build Settings ==> Sub-Directories to Exclude in Recursive Searches. Clean the build folder, and on your next build the build system should be able to see any of these in your code, as expected:
Full-size, single window applications only. You cannot create multi-window SDL applications for iPhone OS. The application window will fill the display, though you have the option of turning on or off the menu-bar (pass SDL_CreateWindow() the flag SDL_WINDOW_BORDERLESS).
Textures:
The optimal texture formats on iOS are SDL_PIXELFORMAT_ABGR8888, SDL_PIXELFORMAT_ABGR8888, SDL_PIXELFORMAT_BGR888, and SDL_PIXELFORMAT_RGB24 pixel formats.
Loading Shared Objects:
This is disabled by default since it seems to break the terms of the iOS SDK agreement for iOS versions prior to iOS 8. It can be re-enabled in SDL_config_iphoneos.h.
Game Center integration might require that you break up your main loop in order to yield control back to the system. In other words, instead of running an endless main loop, you run each frame in a callback function, using:
int SDL_iPhoneSetAnimationCallback(SDL_Window * window, int interval, SDL_iOSAnimationCallback callback, void *callbackParam);
This will set up the given function to be called back on the animation callback, and then you have to return from main() to let the Cocoa event loop run.
e.g.
extern "C"
void ShowFrame(void*)
{
... do event handling, frame logic and rendering ...
}
int main(int argc, char *argv[])
{
... initialize game ...
#ifdef__IPHONEOS__
// Initialize the Game Center for scoring and matchmaking
InitGameCenter();
// Set up the game to run in the window animation callback on iOS
// so that Game Center and so forth works correctly.
Open the package contents of the older Xcode and your newer version of Xcode and copy over the folders in Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/DeviceSupport
Then open the file Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/SDKSettings.plist and add the versions of iOS you want to deploy to the key Root/DefaultProperties/DEPLOYMENT_TARGET_SUGGESTED_VALUES
Open your project and set your deployment target to the desired version of iOS
Finally, remove GameController from the list of frameworks linked by your application and edit the build settings for "Other Linker Flags" and add -weak_framework GameController
iOS
======
Building the Simple DirectMedia Layer for iOS 9.0+
1. Run Xcode and create a new project using the iOS Game template, selecting the Objective C language and Metal game technology.
2. In the main view, delete all files except for Assets and LaunchScreen
3. Right click the project in the main view, select "Add Files...", and add the SDL project, Xcode/SDL/SDL.xcodeproj
4. Select the project in the main view, go to the "Info" tab and under "Custom iOS Target Properties" remove the line "Main storyboard file base name"
5. Select the project in the main view, go to the "Build Settings" tab, select "All", and edit "Header Search Path" and drag over the SDL "Public Headers" folder from the left
6. Select the project in the main view, go to the "Build Phases" tab, select "Link Binary With Libraries", and add SDL2.framework from "Framework-iOS"
7. Select the project in the main view, go to the "General" tab, scroll down to "Frameworks, Libraries, and Embedded Content", and select "Embed & Sign" for the SDL library.
8. In the main view, expand SDL -> Library Source -> main -> uikit and drag SDL_uikit_main.c into your game files
9. Add the source files that you would normally have for an SDL program, making sure to have #include "SDL.h" at the top of the file containing your main() function.
10. Add any assets that your application needs.
11. Enjoy!
TODO: Add information regarding App Store requirements such as icons, etc.
SDL for iPhone supports polling the built in accelerometer as a joystick device. For an example on how to do this, see the accelerometer.c in the demos directory.
The main thing to note when using the accelerometer with SDL is that while the iPhone natively reports accelerometer as floating point values in units of g-force, SDL_JoystickGetAxis() reports joystick values as signed integers. Hence, in order to convert between the two, some clamping and scaling is necessary on the part of the iPhone SDL joystick driver. To convert SDL_JoystickGetAxis() reported values BACK to units of g-force, simply multiply the values by SDL_IPHONE_MAX_GFORCE / 0x7FFF.
Your SDL application for iOS uses OpenGL ES for video by default.
OpenGL ES for iOS supports several display pixel formats, such as RGBA8 and RGB565, which provide a 32 bit and 16 bit color buffer respectively. By default, the implementation uses RGB565, but you may use RGBA8 by setting each color component to 8 bits in SDL_GL_SetAttribute().
If your application doesn't use OpenGL's depth buffer, you may find significant performance improvement by setting SDL_GL_DEPTH_SIZE to 0.
Finally, if your application completely redraws the screen each frame, you may find significant performance improvement by setting the attribute SDL_GL_RETAINED_BACKING to 0.
OpenGL ES on iOS doesn't use the traditional system-framebuffer setup provided in other operating systems. Special care must be taken because of this:
- The drawable Renderbuffer must be bound to the GL_RENDERBUFFER binding point when SDL_GL_SwapWindow() is called.
- The drawable Framebuffer Object must be bound while rendering to the screen and when SDL_GL_SwapWindow() is called.
- If multisample antialiasing (MSAA) is used and glReadPixels is used on the screen, the drawable framebuffer must be resolved to the MSAA resolve framebuffer (via glBlitFramebuffer or glResolveMultisampleFramebufferAPPLE), and the MSAA resolve framebuffer must be bound to the GL_READ_FRAMEBUFFER binding point, before glReadPixels is called.
The above objects can be obtained via SDL_GetWindowWMInfo() (in SDL_syswm.h).
iOS now supports Bluetooth mice on iPad, but by default will provide the mouse input as touch. In order for SDL to see the real mouse events, you should set the key UIApplicationSupportsIndirectInputEvents to true in your Info.plist
Each application installed on iPhone resides in a sandbox which includes its own Application Home directory. Your application may not access files outside this directory.
Once your application is installed its directory tree looks like:
MySDLApp Home/
MySDLApp.app
Documents/
Library/
Preferences/
tmp/
When your SDL based iPhone application starts up, it sets the working directory to the main bundle (MySDLApp Home/MySDLApp.app), where your application resources are stored. You cannot write to this directory. Instead, I advise you to write document files to "../Documents/" and preferences to "../Library/Preferences".
More information on this subject is available here:
The SDL.xcodeproj file now includes a target to build SDL2.xcframework. An xcframework is a new (Xcode 11) uber-framework which can handle any combination of processor type and target OS platform.
In the past, iOS devices were always an ARM variant processor, and the simulator was always i386 or x86_64, and thus libraries could be combined into a single framework for both simulator and device. With the introduction of the Apple Silicon ARM-based machines, regular frameworks would collide as CPU type was no longer sufficient to differentiate the platform. So Apple created the new xcframework library package.
The xcframework target builds into a Products directory alongside the SDL.xcodeproj file, as SDL2.xcframework. This can be brought in to any iOS project and will function properly for both simulator and device, no matter their CPUs. Note that Intel Macs cannot cross-compile for Apple Silicon Macs. If you need AS compatibility, perform this build on an Apple Silicon Mac.
This target requires Xcode 11 or later. The target will simply fail to build if attempted on older Xcodes.
In addition, on Apple platforms, main() cannot be in a dynamically loaded library. This means that iOS apps which used the statically-linked libSDL2.lib and now link with the xcframwork will need to define their own main() to call SDL_UIKitRunApp(), like this:
#ifndef SDL_MAIN_HANDLED
#ifdef main
#undef main
#endif
int
main(int argc, char *argv[])
{
return SDL_UIKitRunApp(argc, argv, SDL_main);
}
#endif /* !SDL_MAIN_HANDLED */
Using an xcFramework is similar to using a regular framework. However, issues have been seen with the build system not seeing the headers in the xcFramework. To remedy this, add the path to the xcFramework in your app's target ==> Build Settings ==> Framework Search Paths and mark it recursive (this is critical). Also critical is to remove "*.framework" from Build Settings ==> Sub-Directories to Exclude in Recursive Searches. Clean the build folder, and on your next build the build system should be able to see any of these in your code, as expected:
Full-size, single window applications only. You cannot create multi-window SDL applications for iPhone OS. The application window will fill the display, though you have the option of turning on or off the menu-bar (pass SDL_CreateWindow() the flag SDL_WINDOW_BORDERLESS).
Textures:
The optimal texture formats on iOS are SDL_PIXELFORMAT_ABGR8888, SDL_PIXELFORMAT_ABGR8888, SDL_PIXELFORMAT_BGR888, and SDL_PIXELFORMAT_RGB24 pixel formats.
Loading Shared Objects:
This is disabled by default since it seems to break the terms of the iOS SDK agreement for iOS versions prior to iOS 8. It can be re-enabled in SDL_config_iphoneos.h.
Game Center integration might require that you break up your main loop in order to yield control back to the system. In other words, instead of running an endless main loop, you run each frame in a callback function, using:
int SDL_iPhoneSetAnimationCallback(SDL_Window * window, int interval, void (*callback)(void*), void *callbackParam);
This will set up the given function to be called back on the animation callback, and then you have to return from main() to let the Cocoa event loop run.
e.g.
extern "C"
void ShowFrame(void*)
{
... do event handling, frame logic and rendering ...
}
int main(int argc, char *argv[])
{
... initialize game ...
#if__IPHONEOS__
// Initialize the Game Center for scoring and matchmaking
InitGameCenter();
// Set up the game to run in the window animation callback on iOS
// so that Game Center and so forth works correctly.
Open the package contents of the older Xcode and your newer version of Xcode and copy over the folders in Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/DeviceSupport
Then open the file Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/SDKSettings.plist and add the versions of iOS you want to deploy to the key Root/DefaultProperties/DEPLOYMENT_TARGET_SUGGESTED_VALUES
Open your project and set your deployment target to the desired version of iOS
Finally, remove GameController from the list of frameworks linked by your application and edit the build settings for "Other Linker Flags" and add -weak_framework GameController
KMSDRM is supported on FreeBSD and OpenBSD. DragonFlyBSD works but requires being a root user. NetBSD isn't supported yet because the application will crash when creating the KMSDRM screen.
WSCONS support has been brought back, but only as an input backend. It will not be brought back as a video backend to ease maintenance.
OpenBSD note: Note that the video backend assumes that the user has read/write permissions to the /dev/drm* devices.
The WSCONS input backend needs read/write access to the /dev/wskbd* devices, without which it will not work properly. /dev/wsmouse must also be read/write accessible, otherwise mouse input will not work.
The evdev devices are only accessible to the root user by default. Edit devfs rules to allow access to such devices. The /dev/kbd* devices are also only accessible to the root user by default. Edit devfs rules to allow access to such devices.
KMSDRM is supported on FreeBSD and OpenBSD. DragonFlyBSD works but requires being a root user. NetBSD isn't supported yet because the application will crash when creating the KMSDRM screen.
WSCONS support has been brought back, but only as an input backend. It will not be brought back as a video backend to ease maintenance.
OpenBSD note: Note that the video backend assumes that the user has read/write permissions to the /dev/drm* devices.
The WSCONS input backend needs read/write access to the /dev/wskbd* devices, without which it will not work properly. /dev/wsmouse must also be read/write accessible, otherwise mouse input will not work.
The evdev devices are only accessible to the root user by default. Edit devfs rules to allow access to such devices. The /dev/kbd* devices are also only accessible to the root user by default. Edit devfs rules to allow access to such devices.
- SDL2main should be used to ensure ROMFS is enabled.
- By default, the extra L2 cache and higher clock speeds of the New 2/3DS lineup are enabled. If you wish to turn it off, use `osSetSpeedupEnable(false)` in your main function.
-`SDL_GetBasePath` returns the romfs root instead of the executable's directory.
- The Nintendo 3DS uses a cooperative threading model on a single core, meaning a thread will never yield unless done manually through the `SDL_Delay` functions, or blocking waits (`SDL_LockMutex`, `SDL_SemWait`, `SDL_CondWait`, `SDL_WaitThread`). To avoid starving other threads, `SDL_SemTryWait` and `SDL_SemWaitTimeout` will yield if they fail to acquire the semaphore, see https://github.com/libsdl-org/SDL/pull/6776 for more information.
# Nintendo 3DS
SDL port for the Nintendo 3DS [Homebrew toolchain](https://devkitpro.org/) contributed by:
- SDL2main should be used to ensure ROMFS is enabled.
- By default, the extra L2 cache and higher clock speeds of the New 2/3DS lineup are enabled. If you wish to turn it off, use `osSetSpeedupEnable(false)` in your main function.
-`SDL_GetBasePath` returns the romfs root instead of the executable's directory.
- The Nintendo 3DS uses a cooperative threading model on a single core, meaning a thread will never yield unless done manually through the `SDL_Delay` functions, or blocking waits (`SDL_LockMutex`, `SDL_SemWait`, `SDL_CondWait`, `SDL_WaitThread`). To avoid starving other threads, `SDL_SemTryWait` and `SDL_SemWaitTimeout` will yield if they fail to acquire the semaphore, see https://github.com/libsdl-org/SDL/pull/6776 for more information.
The PS2 port has a special Hint for having a dynamic VSYNC. The Hint is `SDL_HINT_PS2_DYNAMIC_VSYNC`.
If you enabled the dynamic vsync having as well `SDL_RENDERER_PRESENTVSYNC` enabled, then if the app is not able to run at 60 FPS, automatically the `vsync` will be disabled having a better performance, instead of droping FPS to 30.
## Notes
If you trying to debug a SDL app through [ps2client](https://github.com/ps2dev/ps2client) you need to avoid the IOP reset, otherwise you will lose the conection with your computer.
So to avoid the reset of the IOP CPU, you need to call to the macro `SDL_PS2_SKIP_IOP_RESET();`.
It could be something similar as:
```c
.....
SDL_PS2_SKIP_IOP_RESET();
int main(int argc, char *argv[])
{
.....
```
For a release binary is recommendable to reset the IOP always.
Remember to do a clean compilation everytime you enable or disable the `SDL_PS2_SKIP_IOP_RESET` otherwise the change won't be reflected.
The PS2 port has a special Hint for having a dynamic VSYNC. The Hint is `SDL_HINT_PS2_DYNAMIC_VSYNC`.
If you enabled the dynamic vsync having as well `SDL_RENDERER_PRESENTVSYNC` enabled, then if the app is not able to run at 60 FPS, automatically the `vsync` will be disabled having a better performance, instead of droping FPS to 30.
## Notes
If you trying to debug a SDL app through [ps2client](https://github.com/ps2dev/ps2client) you need to avoid the IOP reset, otherwise you will lose the conection with your computer.
So to avoid the reset of the IOP CPU, you need to call to the macro `SDL_PS2_SKIP_IOP_RESET();`.
It could be something similar as:
```c
.....
SDL_PS2_SKIP_IOP_RESET();
int main(int argc, char *argv[])
{
.....
```
For a release binary is recommendable to reset the IOP always.
Remember to do a clean compilation everytime you enable or disable the `SDL_PS2_SKIP_IOP_RESET` otherwise the change won't be reflected.
The video driver currently provides full screen video support with keyboard and mouse input. Windowed mode is not yet supported, but is planned in the future. Only software rendering is supported.
The filesystem APIs return either Unix-style paths or RISC OS-style paths based on the value of the `__riscosify_control` symbol, as is standard for UnixLib functions.
The audio, loadso, thread and timer APIs are currently provided by UnixLib.
GCC atomics are currently broken on some platforms, meaning it's currently necessary to compile with `--disable-gcc-atomics` using autotools or `-DSDL_GCC_ATOMICS=OFF` using CMake.
The joystick, locale and power APIs are not yet implemented.
The video driver currently provides full screen video support with keyboard and mouse input. Windowed mode is not yet supported, but is planned in the future. Only software rendering is supported.
The filesystem APIs return either Unix-style paths or RISC OS-style paths based on the value of the `__riscosify_control` symbol, as is standard for UnixLib functions.
The audio, loadso, thread and timer APIs are currently provided by UnixLib.
GCC atomics are currently broken on some platforms, meaning it's currently necessary to compile with `--disable-gcc-atomics` using autotools or `-DSDL_GCC_ATOMICS=OFF` using CMake.
The joystick, locale and power APIs are not yet implemented.
The linux touch system is currently based off event streams, and proc/bus/devices. The active user must be given permissions to read /dev/input/TOUCHDEVICE, where TOUCHDEVICE is the event stream for your device. Currently only Wacom tablets are supported. If you have an unsupported tablet contact me at jim.tla+sdl_touch@gmail.com and I will help you get support for it.
Mac:
The Mac and iPhone APIs are pretty. If your touch device supports them then you'll be fine. If it doesn't, then there isn't much we can do.
iPhone:
Works out of box.
Windows:
Unfortunately there is no windows support as of yet. Support for Windows 7 is planned, but we currently have no way to test. If you have a Windows 7 WM_TOUCH supported device, and are willing to help test please contact me at jim.tla+sdl_touch@gmail.com
SDL provides the ability to access the underlying SDL_Finger structures.
These structures should _never_ be modified.
The following functions are included from SDL_touch.h
To get a SDL_TouchID call SDL_GetTouchDevice(int index).
This returns a SDL_TouchID.
IMPORTANT: If the touch has been removed, or there is no touch with the given index, SDL_GetTouchDevice() will return 0. Be sure to check for this!
The number of touch devices can be queried with SDL_GetNumTouchDevices().
A SDL_TouchID may be used to get pointers to SDL_Finger.
SDL_GetNumTouchFingers(touchID) may be used to get the number of fingers currently down on the device.
The most common reason to access SDL_Finger is to query the fingers outside the event. In most cases accessing the fingers is using the event. This would be accomplished by code like the following:
float x = event.tfinger.x;
float y = event.tfinger.y;
To get a SDL_Finger, call SDL_GetTouchFinger(SDL_TouchID touchID, int index), where touchID is a SDL_TouchID, and index is the requested finger.
This returns a SDL_Finger *, or NULL if the finger does not exist, or has been removed.
A SDL_Finger is guaranteed to be persistent for the duration of a touch, but it will be de-allocated as soon as the finger is removed. This occurs when the SDL_FINGERUP event is _added_ to the event queue, and thus _before_ the SDL_FINGERUP event is polled.
As a result, be very careful to check for NULL return values.
The linux touch system is currently based off event streams, and proc/bus/devices. The active user must be given permissions to read /dev/input/TOUCHDEVICE, where TOUCHDEVICE is the event stream for your device. Currently only Wacom tablets are supported. If you have an unsupported tablet contact me at jim.tla+sdl_touch@gmail.com and I will help you get support for it.
Mac:
The Mac and iPhone APIs are pretty. If your touch device supports them then you'll be fine. If it doesn't, then there isn't much we can do.
iPhone:
Works out of box.
Windows:
Unfortunately there is no windows support as of yet. Support for Windows 7 is planned, but we currently have no way to test. If you have a Windows 7 WM_TOUCH supported device, and are willing to help test please contact me at jim.tla+sdl_touch@gmail.com
SDL provides the ability to access the underlying SDL_Finger structures.
These structures should _never_ be modified.
The following functions are included from SDL_touch.h
To get a SDL_TouchID call SDL_GetTouchDevice(int index).
This returns a SDL_TouchID.
IMPORTANT: If the touch has been removed, or there is no touch with the given index, SDL_GetTouchDevice() will return 0. Be sure to check for this!
The number of touch devices can be queried with SDL_GetNumTouchDevices().
A SDL_TouchID may be used to get pointers to SDL_Finger.
SDL_GetNumTouchFingers(touchID) may be used to get the number of fingers currently down on the device.
The most common reason to access SDL_Finger is to query the fingers outside the event. In most cases accessing the fingers is using the event. This would be accomplished by code like the following:
float x = event.tfinger.x;
float y = event.tfinger.y;
To get a SDL_Finger, call SDL_GetTouchFinger(SDL_TouchID touchID, int index), where touchID is a SDL_TouchID, and index is the requested finger.
This returns a SDL_Finger *, or NULL if the finger does not exist, or has been removed.
A SDL_Finger is guaranteed to be persistent for the duration of a touch, but it will be de-allocated as soon as the finger is removed. This occurs when the SDL_FINGERUP event is _added_ to the event queue, and thus _before_ the SDL_FINGERUP event is polled.
As a result, be very careful to check for NULL return values.
You can either use the precompiled libraries from the [SDL](https://www.libsdl.org/download.php) web site, or you can build SDL
yourself.
### Building SDL
0. To build SDL, your machine must, at a minimum, have the DirectX9.0c SDK installed. It may or may not be retrievable from
the [Microsoft](https://www.microsoft.com) website, so you might need to locate it [online](https://duckduckgo.com/?q=directx9.0c+sdk+download&t=h_&ia=web).
_Editor's note: I've been able to successfully build SDL using Visual Studio 2019 **without** the DX9.0c SDK_
1. Open the Visual Studio solution file at `./VisualC/SDL.sln`.
2. Your IDE will likely prompt you to upgrade this solution file to whatever later version of the IDE you're using. In the `Retarget Projects` dialog,
all of the affected project files should be checked allowing you to use the latest `Windows SDK Version` you have installed, along with
the `Platform Toolset`.
If you choose *NOT* to upgrade to use the latest `Windows SDK Version` or `Platform Toolset`, then you'll need the `Visual Studio 2010 Platform Toolset`.
3. Build the `.dll` and `.lib` files by right clicking on each project in turn (Projects are listed in the _Workspace_
panel in the _FileView_ tab), and selecting `Build`.
You may get a few warnings, but you should not get any errors.
Later, we will refer to the following `.lib` and `.dll` files that have just been generated:
- `./VisualC/Win32/Debug/SDL2.dll` or `./VisualC/Win32/Release/SDL2.dll`
- `./VisualC/Win32/Debug/SDL2.lib` or `./VisualC/Win32/Release/SDL2.lib`
- `./VisualC/Win32/Debug/SDL2main.lib` or `./VisualC/Win32/Release/SDL2main.lib`
_Note for the `x64` versions, just replace `Win32` in the path with `x64`_
### Creating a Project with SDL
- Create a project as a `Win32 Application`.
- Create a C++ file for your project.
- Set the C runtime to `Multi-threaded DLL` in the menu:
I hope that this document has helped you get through the most difficult part of using the SDL: installing it.
Suggestions for improvements should be posted to the [Github Issues](https://github.com/libsdl-org/SDL/issues).
### Credits
Thanks to [Paulus Esterhazy](mailto:pesterhazy@gmx.net), for the work on VC++ port.
This document was originally called "VisualC.txt", and was written by [Sam Lantinga](mailto:slouken@libsdl.org).
Later, it was converted to HTML and expanded into the document that you see today by [Lion Kimbro](mailto:snowlion@sprynet.com).
Minor Fixes and Visual C++ 7 Information (In Green) was added by [James Turk](mailto:james@conceptofzero.net)
Using SDL with Microsoft Visual C++
===================================
### by Lion Kimbro with additions by James Turk
You can either use the precompiled libraries from the [SDL](https://www.libsdl.org/download.php) web site, or you can build SDL
yourself.
### Building SDL
0. To build SDL, your machine must, at a minimum, have the DirectX9.0c SDK installed. It may or may not be retrievable from
the [Microsoft](https://www.microsoft.com) website, so you might need to locate it [online](https://duckduckgo.com/?q=directx9.0c+sdk+download&t=h_&ia=web).
_Editor's note: I've been able to successfully build SDL using Visual Studio 2019 **without** the DX9.0c SDK_
1. Open the Visual Studio solution file at `./VisualC/SDL.sln`.
2. Your IDE will likely prompt you to upgrade this solution file to whatever later version of the IDE you're using. In the `Retarget Projects` dialog,
all of the affected project files should be checked allowing you to use the latest `Windows SDK Version` you have installed, along with
the `Platform Toolset`.
If you choose *NOT* to upgrade to use the latest `Windows SDK Version` or `Platform Toolset`, then you'll need the `Visual Studio 2010 Platform Toolset`.
3. Build the `.dll` and `.lib` files by right clicking on each project in turn (Projects are listed in the _Workspace_
panel in the _FileView_ tab), and selecting `Build`.
You may get a few warnings, but you should not get any errors.
Later, we will refer to the following `.lib` and `.dll` files that have just been generated:
- `./VisualC/Win32/Debug/SDL2.dll` or `./VisualC/Win32/Release/SDL2.dll`
- `./VisualC/Win32/Debug/SDL2.lib` or `./VisualC/Win32/Release/SDL2.lib`
- `./VisualC/Win32/Debug/SDL2main.lib` or `./VisualC/Win32/Release/SDL2main.lib`
_Note for the `x64` versions, just replace `Win32` in the path with `x64`_
### Creating a Project with SDL
- Create a project as a `Win32 Application`.
- Create a C++ file for your project.
- Set the C runtime to `Multi-threaded DLL` in the menu:
* gles1/gles2 support and renderers are disabled by default and can be enabled by configuring with `-DVIDEO_VITA_PVR=ON`
These renderers support 720p and 1080i resolutions. These can be specified with:
`SDL_setenv("VITA_RESOLUTION", "720", 1);` and `SDL_setenv("VITA_RESOLUTION", "1080", 1);`
* Desktop GL 1.X and 2.X support and renderers are also disabled by default and also can be enabled with `-DVIDEO_VITA_PVR=ON` as long as gl4es4vita is present in your SDK.
They support the same resolutions as the gles1/gles2 backends and require specifying `SDL_setenv("VITA_PVR_OGL", "1", 1);`
anytime before video subsystem initialization.
* gles2 support via PIB is disabled by default and can be enabled by configuring with `-DVIDEO_VITA_PIB=ON`
* By default SDL emits mouse events for touch events on every touchscreen.
Vita has two touchscreens, so it's recommended to use `SDL_SetHint(SDL_HINT_TOUCH_MOUSE_EVENTS, "0");` and handle touch events instead.
Individual touchscreens can be disabled with:
`SDL_setenv("VITA_DISABLE_TOUCH_FRONT", "1", 1);` and `SDL_setenv("VITA_DISABLE_TOUCH_BACK", "1", 1);`
* Support for L2/R2/R3/R3 buttons, haptic feedback and gamepad led only available on PSTV, or when using external ds4 gamepad on vita.
PS Vita
=======
SDL port for the Sony Playstation Vita and Sony Playstation TV
Credit to
* xerpi, cpasjuste and rsn8887 for initial (vita2d) port
* vitasdk/dolcesdk devs
* CBPS discord (Namely Graphene and SonicMastr)
Building
--------
To build for the PSVita, make sure you have vitasdk and cmake installed and run:
* gles1/gles2 support and renderers are disabled by default and can be enabled by configuring with `-DVIDEO_VITA_PVR=ON`
These renderers support 720p and 1080i resolutions. These can be specified with:
`SDL_setenv("VITA_RESOLUTION", "720", 1);` and `SDL_setenv("VITA_RESOLUTION", "1080", 1);`
* Desktop GL 1.X and 2.X support and renderers are also disabled by default and also can be enabled with `-DVIDEO_VITA_PVR=ON` as long as gl4es4vita is present in your SDK.
They support the same resolutions as the gles1/gles2 backends and require specifying `SDL_setenv("VITA_PVR_OGL", "1", 1);`
anytime before video subsystem initialization.
* gles2 support via PIB is disabled by default and can be enabled by configuring with `-DVIDEO_VITA_PIB=ON`
* By default SDL emits mouse events for touch events on every touchscreen.
Vita has two touchscreens, so it's recommended to use `SDL_SetHint(SDL_HINT_TOUCH_MOUSE_EVENTS, "0");` and handle touch events instead.
Individual touchscreens can be disabled with:
`SDL_setenv("VITA_DISABLE_TOUCH_FRONT", "1", 1);` and `SDL_setenv("VITA_DISABLE_TOUCH_BACK", "1", 1);`
* Support for L2/R2/R3/R3 buttons, haptic feedback and gamepad led only available on PSTV, or when using external ds4 gamepad on vita.
Uint32timestamp;/**< In milliseconds, populated using SDL_GetTicks() */
SDL_JoystickIDwhich;/**< The joystick instance id */
Sint32sensor;/**< The type of the sensor, one of the values of SDL_SensorType */
Sint32sensor;/**< The type of the sensor, one of the values of ::SDL_SensorType */
floatdata[3];/**< Up to 3 values from the sensor, as defined in SDL_sensor.h */
Uint64timestamp_us;/**< The timestamp of the sensor reading in microseconds, if the hardware provides this information. */
}SDL_ControllerSensorEvent;
/**
*Audiodeviceeventstructure(event.adevice.*)
*\briefAudiodeviceeventstructure(event.adevice.*)
*/
typedefstructSDL_AudioDeviceEvent
{
Uint32type;/**< SDL_AUDIODEVICEADDED, or SDL_AUDIODEVICEREMOVED */
Uint32type;/**< ::SDL_AUDIODEVICEADDED, or ::SDL_AUDIODEVICEREMOVED */
Uint32timestamp;/**< In milliseconds, populated using SDL_GetTicks() */
Uint32which;/**< The audio device index for the ADDED event (valid until next SDL_GetNumAudioDevices() call), SDL_AudioDeviceID for the REMOVED event */
Uint8iscapture;/**< zero if an output device, non-zero if a capture device. */
Loaded 100 of 702 files, more files were not shown because too many files have changed in this diff.
Show more
Reference in new issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
alufolie91
indev
SteelT
Alug
orbitalviolet
Roberto Ierusalimschy
NepDisk
GenericHeroGuy
Gustaf Alhäll
James R
Monster Iestyn
MIDIMan
romoney5
Eidolon
GLide KS
mazmazz
entryway
AJ Martinez
Zwip-Zwap Zapony
toaster
minenice55
X.organic
Alug
PAS
cobalt2727
LJ Sonic
Blue Staggo
GoldenTails
AJ Martinez
Alam Ed Arias
K J
Lactozilla
Sally Coolatta
JugadorXEI
chromaticpipe
Logan Aerl Arias
sphere
Anonimus
GenericHeroGuy
themixedupstuff
NepDisk