kenix3 / libultraship Goto Github PK
View Code? Open in Web Editor NEWPorting games to the PC
License: MIT License
Porting games to the PC
License: MIT License
libultraship/src/graphic/Fast3D/gfx_dxgi.cpp
Lines 585 to 588 in 70c3201
I would like to point out that the Windows scheduler cannot actually do 100 ns on a wait, even at the highest possible timer resolution :)
For proper framepacing, you should adopt something more conservative:
Timer = Deadline - 1 ms
Busy-wait the remaining time, checking QPC and calling YieldProcessor (...).
I know this sounds inefficient, but in fact it is not.
The amount of time that you'll spend busy-waiting because the next frame deadline is less than 1 ms is probably 10-20% of your total wait time at 60 FPS. And you'll never -miss- a frame, unlike the current design that's constantly going to return after the frame deadline (because, again, 100 ns scheduling is ridiculous).
SDL provides a great abstraction layer for audio. https://github.com/Kenix3/libultraship/blob/main/src/audio/SDLAudioPlayer.cpp accomplishes in 44 lines what takes https://github.com/Kenix3/libultraship/blob/main/src/audio/PulseAudioPlayer.cpp 191.
SDL supports many different audio drivers https://wiki.libsdl.org/SDL2/FAQUsingSDL#linux_1 (including pulseaudio)
I propose we remove PulseAudioPlayer
and rely on SDL audio for linux instead.
The interface will remain unchanged where the user will still identify the cvar by a string eg gCosmetics.KokiriTunic.RainbowMode
, but the underlying JSON this will be stored as a nested structure
If I exited SoH while it was in fullscreen and at my second monitor, the next start is always in fullscreen at my primary monitor. after that toggling back to windowed makes the window jump back to my secondary monitor.
TLDR: Monitor saves fine for windowed mode. It doesn't in fullscreen.
SoH build with PR HarbourMasters/Shipwright#2881
they're all CVar_*
at the moment
SoH version: Spock Charlie 7.0.2
If you dodge bongo bongo's fist attack the hand doesnt come back and its just stay stuck in that state.
i later did some testing and it seems like this occurs if no clip is enabled
not sure what it'll take to get this working consistently, but it seems to be a problem across multiple different controllers
While auditing the code for libultraship I noticed we have an older version of the Fast3D license. After thinking it through, I think the libultraship fork of Fast3D would be better served with the MIT license than the new Fast3D license. I have already talked this over with @Emill, and he is good with the change.
Two different groups of people are getting pinged for this new license: libultraship contributors and Fast3D contributors.
To the libultraship contributors: Your contributions are under the current license on the LUS Fast3D fork. This license does not work for projects that will want to use libultraship. We need at least the newest Fast3D license, but MIT matches the rest of libultraship and thus makes sense.
To the Fast3D contributors: First, sorry to ping you on a project you didn't directly commit to. We are using a fork of Fast3D developed to allow for binary redistribution. I thought we forked from a Fast3D that has the newest Fast3D license. As mentioned earlier, I recently noticed we had the old license that doesn't allow us to allow binary distribution ports. Ports made on libultraship are meant to have assets loaded externally and not compiled in, so there should be no real concern to binary distribution of ports made with libultraship. I've already discussed this with @Emill, the original author of Fast3D, and he said the switch to MIT license for this fork is fine.
The newest Fast3D license:
https://github.com/Emill/n64-fast3d-engine/blob/master/LICENSE.txt
The current license on the LUS Fast3D fork:
https://github.com/Kenix3/libultraship/blob/main/src/graphic/Fast3D/LICENSE.txt
The new proposed license:
MIT License
Copyright (c) 2020 Emill, MaikelChan
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.
Affirming to the new license will mean that any contributions you've made to the Fast3D project, either in this repository (https://github.com/Kenix3/libultraship), the HarbourMasters/Shipwright repository (https://github.com/HarbourMasters/Shipwright), or the original Fast3D repository (https://github.com/Emill/n64-fast3d-engine) to be licensed under the MIT license as proposed above. This also means the original location of the moved Fast3D files. The changes are currently represented in the Fast3D directory in libultraship at https://github.com/Kenix3/libultraship/tree/main/src/graphic/Fast3D.
Please post in this issue whether or not you affirm that the license change is OK and that you have the ability to submit this code under the MIT license. Please also post if there are any comments or questions that we can address.
Thankyou everyone.
libultraship contributors:
@Kenix3 @NEstelami @KiritoDv @dcvz @louist103 @Emill @briaguya-ai @Rozelette @GaryOderNichts @garrettjoecox @jbodner09 @GreatArgorath @Random06457 @AloXado320 @th-2021 @JoshDuMan @andrewwvc @MaikelChan
Fast3D contributors:
@Emill @MaikelChan @DarkRTA @AloXado320 @aglab2
We should also implement osMotor calls so that we have a correct API for rumbling.
right now we have
libultraship/include/libultraship/libultra/controller.h
Lines 101 to 108 in 883fb45
it's not clear what VSTICK means, and on the analog side of things we have
libultraship/include/libultraship/libultra/controller.h
Lines 123 to 124 in 883fb45
libultraship/include/libultraship/libultra/controller.h
Lines 128 to 129 in 883fb45
i think it would make sense to switch these to be
#define BTN_LSTICKLEFT 0x10000
#define BTN_LSTICKRIGHT 0x20000
#define BTN_LSTICKDOWN 0x40000
#define BTN_LSTICKUP 0x80000
#define BTN_RSTICKUP 0x100000
#define BTN_RSTICKDOWN 0x200000
#define BTN_RSTICKLEFT 0x400000
#define BTN_RSTICKRIGHT 0x800000
and
/* 0x02 */ int8_t left_stick_x;
/* 0x03 */ int8_t left_stick_y;
soh issue here HarbourMasters/Shipwright#2309
seems the pixels on the edge get duplicated when resizing. seems like something isn't being updated properly during resize
when we set using SetColor24
the Color24
variable is set
libultraship/src/config/ConsoleVariable.cpp
Lines 127 to 135 in 6671d7e
but then when we go to save the Color
variable is read
libultraship/src/config/ConsoleVariable.cpp
Lines 186 to 199 in 6671d7e
leading to {0, 0, 0}
always being saved for Color24
libultraship/src/graphic/Fast3D/gfx_pc.cpp
Line 2484 in 0aa972b
libultraship/src/graphic/Fast3D/gfx_pc.cpp
Lines 2527 to 2531 in 0aa972b
The issue comes from a fix on the ControlDeck, when the InputEditor is open or any other view, the game stops reading data from the controllers, because of that the stick preview and the gyro calibration don't work, as a few other bugs related to this.
This patch should fix it, its tested on both pc and switch
Demo:
we currently check to see if the window with the title "Input Editor" open and if there is we block game input. we should do this in a better way
it shouldn't have lib twice
From what I can tell all windows created within the port will persist their window size and position, with the exception of the main game window.
This has been a common pain point for people who do not play fullscreen.
They can be found here: https://github.com/HarbourMasters/libultraship
We'll want to bring in the implementations for libultra functions, and the Fast3D changes.
i would like to allow users to set a deadzone with a unit that means something. the current deadzone is just a number with no context. i think it would be ideal to have this number be a percentage, with 100% meaning no inputs from the stick are counted because 100% of the stick range is included in the deadzone.
if SDL always reported a value that fit within a circle this wouldn't be a problem. sqrt(x^2 + x^2)
would be at max MAX_AXIS_RANGE
and we could just have the user set a percentage of MAX_AXIS_RANGE
, but we can't count on that being the case.
in my testing on an xbox controller (with a circular gate on the analog stick), i've been able to get normalized values (MAX_AXIS_RANGE/MAX_SDL_RANGE
), that give a radius of closer to 90
(as opposed to 85
) (~64 and ~63 for x and y respectively)
for #350 i'm going to go ahead and just do a percentage of MAX_AXIS_RANGE
, as that still feels better than what we have now
try setting the deadzone in the current controller config window somewhere between 85 and 95 and look at the input preview, you'll see the oddities
This is not functional on firmware 16.0.0 as the service accessible with pl:s is no longer used to retrieve fonts. This should be changed to use pl:u instead.
We already have the ability to register/get/set Cvars but nothing for removing/clearing cvars. This would be useful for a number of reasons, and should remove the key/value from the underlying JSON
Some Windows users have reported a crash on launch that happens in the LUS::Window init -> gfx_init
Investigation revealed that it was an issue with DX11 on their machines. Since DX11 is the default renderer for Windows when there is no existing configuration, this leaves the user stuck without the ability to run. Guiding the user to modify their configuration to use OpenGL instead resolved the crash.
In the case of Windows, it would be nice to be able to detect a gfx_init failure and try to fallback to the OpenGL renderer so that users are not required to manually modify configuration files.
Here is the crash log when using DX11 on the problematic machines:
Registers:
RAX: 0x0000000000000000
RCX: 0x0000000200000001
RDX: 0x0000000100000004
RBX: 0x00007FF640D67CE8
RSP: 0x0000008190B0DFF0
RBP: 0x0000008190B0E260
RSI: 0x0000008190B0E160
RDI: 0x0000000019930520
R9: 0x0000000100000060
R10: 0x0000006000000001
R11: 0x0000000000000000
R12: 0x0000000000000000
R13: 0x0000000000000003
R14: 0x0000000000000000
R15: 0x00007FF640AD6D50
RIP: 0x00007FFFEBB2CB69
EFLAGS: 0x00000202
At RaiseExceptionAddr: 0x00007FFFEBB2CB00
In: C:\Windows\System32\KERNELBASE.dll
_CxxThrowException in D:\a\_work\1\s\src\vctools\crt\vcruntime\src\eh\throw.cppLine: 75At ?ThrowIfFailed@@YAXJ@ZAddr: 0x00007FF640791810
In: C:\Users\TOSHIBA\Desktop\zelda ocarina of time\soh.exe
At ?do_get@?$num_get@DV?$istreambuf_iterator@DU?$char_traits@D@std@@@std@@@std@@MEBA?AV?$istreambuf_iterator@DU?$char_traits@D@std@@@2@V32@0AEAVios_base@2@AEAHAEA_N@ZAddr: 0x00007FF6407889B0
In: C:\Users\TOSHIBA\Desktop\zelda ocarina of time\soh.exe
At ?gfx_init@@YAXPEAUGfxWindowManagerAPI@@PEAUGfxRenderingAPI@@PEBD_NII@ZAddr: 0x00007FF640755CA0
In: C:\Users\TOSHIBA\Desktop\zelda ocarina of time\soh.exe
At ?Init@Window@LUS@@QEAAXXZAddr: 0x00007FF64073FB40
In: C:\Users\TOSHIBA\Desktop\zelda ocarina of time\soh.exe
At ?InitWindow@Context@LUS@@QEAAXXZAddr: 0x00007FF64073BD50
In: C:\Users\TOSHIBA\Desktop\zelda ocarina of time\soh.exe
At ?Init@Context@LUS@@QEAAXAEBV?$vector@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@V?$allocator@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@2@@std@@AEBV?$unordered_set@IU?$hash@I@std@@U?$equal_to@I@2@V?$allocator@I@2@@4@I@ZAddr: 0x00007FF64073A190
In: C:\Users\TOSHIBA\Desktop\zelda ocarina of time\soh.exe
At ?CreateInstance@Context@LUS@@SA?AV?$shared_ptr@VContext@LUS@@@std@@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@4@0AEBV?$vector@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@V?$allocator@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@2@@4@AEBV?$unordered_set@IU?$hash@I@std@@U?$equal_to@I@2@V?$allocator@I@2@@4@I@ZAddr: 0x00007FF640739C00
In: C:\Users\TOSHIBA\Desktop\zelda ocarina of time\soh.exe
OTRGlobals::OTRGlobals in D:\a\Shipwright\Shipwright\soh\soh\OTRGlobals.cppLine: 244InitOTR in D:\a\Shipwright\Shipwright\soh\soh\OTRGlobals.cppLine: 745SDL_main in D:\a\Shipwright\Shipwright\soh\src\code\main.cLine: 65main_getcmdline in D:\a\Shipwright\Shipwright\build-windows\vcpkg\buildtrees\sdl2\src\ase-2.26.5-fdc15bb8fb.clean\src\main\windows\SDL_windows_main.cLine: 82__scrt_common_main_seh in D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inlLine: 288At BaseThreadInitThunkAddr: 0x00007FFFECFE75F0
In: C:\Windows\System32\KERNEL32.DLL
At RtlUserThreadStartAddr: 0x00007FFFEE122680
In: C:\Windows\SYSTEM32\ntdll.dll
Per a conversation had about it, "gSPBranchList should be the equivalent of gSPDisplayList(), followed by gSPEndDisplayList()". Libultraship's implementation of it can be found here, and it is not a correct implementation:
Instead of:
} else {
cmd = (Gfx*)seg_addr(cmd->words.w1);
}
It should probably be something like:
} else {
cmd++;
uint64_t hash = ((uint64_t)cmd->words.w0 << 32) + cmd->words.w1;
cmd = (Gfx*)ResourceGetDataByCrc(hash);
--cmd; // increase after break
}
Thanks for the suggested fix, @Rozelette .
We can find some simple open source N64 code/game to port using LUS to use as an example project on how to implement LUS.
Create some instructions as well on how LUS was integrated into the example project.
Ideally this example project would build for both N64 and PC.
All of the OOT specific asset code files and factories should be moved to an LUS module.
I'm thinking that the ResourceLoader stays, but keeps all of the resource types in a map. It exposes a method to register a type. ZAPDTR (or some new module for LUS) will have all of the factories and data classes like PlayerAnimation.
This should also accompany a cleanup of the Resource.h header and it's helper classes. Anything OOT/ZAPD specific should go to ZAPDTR/SOH.
Further ResourceLoader should be a shared_ptr on the resorucemgr, and make everything a class member rather than static function.
Also need to update ResourceType enum.
I was told to redirect my issue here.
Original thread:
HarbourMasters/Shipwright#2083
With LUS 1.0.0 it seems input from the on screen keyboard in SteamOS no longer works. Specifically any key that would type a character. Arrow keys and backspace appear to be unaffected.
Have not tested on other Linux OS or other platforms yet.
Any class that has a destructor also has a copy assignment operator and copy constructor.
Evaluate any class with a pointer (like Window and SDLController) or shared_ptr for copy assignment/constructor.
the logic currently lives in
ControlDeck
Controller
DummyController
KeyboardController
SDLController
so the process for getting controller data into a game is currently
libultraship/src/public/libultra/os.cpp
Lines 36 to 40 in 1c58020
this part makes a lot of sense, we need to have something in LUS that gets player input data intoOSContPad
it then gets a little messier
libultraship/src/controller/ControlDeck.cpp
Lines 86 to 113 in 1c58020
in this method we've already hit some messy logic. trying to handle "Auto" this way feels like a workaround. that being said, the basic flow makes a lot of sense
void ControlDeck::WriteToPad(OSContPad* pad) {
mPads = pad;
for (size_t i = 0; i < mPortList.size(); i++) {
const std::shared_ptr<Controller> controller = mDevices[mPortList[i]];
controller->ReadToPad(&pad[i], i);
}
}
this brings us into
libultraship/src/controller/Controller.cpp
Lines 143 to 144 in 1c58020
and this is where we start to see a pattern that i think shows the most room for improvement. we're constantly passing around portIndex
all of the controllers need this to know which OSContPad
to write do during ReadDevice
, so it makes sense that this is happening, but it also leads to ReadDevice
methods with a ton of logic in them. The one in SDLController
is nearly 200 lines long
libultraship/src/controller/SDLController.cpp
Lines 111 to 302 in 1c58020
i propose we restructure where the inheritance lives. so our /controller/
directory could instead look like
ControlDeck
Controller
Mapping
(or ButtonMapping
but that seems odd if we use it for axes, or Binding
)
DummyMapping
KeyboardMapping
SDLMapping
in this proposed architecture nothing would inherit from controller, and controller would have a bunch of mappings as members. instead of calling ReadDevice
in ReadToPad
, we would ask each mapping for the data we need
Controller
, simplifying implementation of new input backends.OSContPad
In order to affirm the project license after moving this project from https://github.com/HarbourMasters/Shipwright to the repository at https://github.com/kenix3/libultraship, we need to ask everyone to affirm the license in the repository.
Please comment affirming you agree, and are able, to having your prior contributions licensed under the terms described the license in this repository.
We're largely asking this because the move constituted leaving the subrepo. The GitHub ToS is not perfectly clear how licenses apply to subrepos, so to be safe we are asking for an affirmation. Beyond that, we also changed the copyright line in the license file as "Harbour Masters" does not currently exist as a legal entity. Thankyou.
@Kenix3 @NEstelami @KiritoDv @dcvz @louist103 @Emill @briaguya-ai @leggettc18 @Rozelette @garrettjoecox @GaryOderNichts @Sirius902 @aMannus @Baoulettes @lilDavid @MelonSpeedruns @jbodner09 @PurpleHato @GreatArgorath @qurious-pixel @vaguerant @earthcrafterman @Random06457 @AloXado320 @th-2021 @JoshDuMan @Alto1772 @Archez @Sarge-117 @crowell @sholdee @m4xw @JakeEdvenson @Nycz-lab @InfoManiac742 @guaycuru @modestposer @Stormghetti @Dog @ChristopherJTrent @agamache @TheLegendOfLame @andrewwvc @ProjectRevoTPP @sparklingshampoo @MaikelChan @kev4cards
hold
vs nunchuck.hold
)___ToHotkeyMapping
(this would get us remappable hotkeys)ControllerStick
/ControllerButton
/ControllerGyro
/ControllerRumble
/ControllerLED
(maybe just wait and do this as part of attachments)Power settings (e.g. Monitor standby) is lost after playing SOH on Windows. Version is latest (7.1.1).
the current LUS implementation of OSContPad
includes things beyond what exists on the n64 (multiple analog sticks, gyro), but is still very opinionated as to what can exist on the pad.
i think in order to satisfy the two port dev user stories from #342 it could be helpful to add some flexibility here.
To satisfy
As a developer of a port using LUS, I should be able to get up and running without building my own controller mapping/configuration menu.
it could be helpful to provide controller functionality that utilizes an OSContPad
that matches the authentic data structure. Only including n64 buttons/one analog stick. The existing LUS controller functionality could then be provided via OSContPadExtended
, which would provide the default "modern controller" version of OSContPad
that exists in LUS today (n64 controller + a few extra things)
To satisfy
As a developer of a port using LUS, I should be able to provide a tailored controller mapping/configuration experience for players.
we would want to provide the ability for any given port could provide their own OSContPad
structure that can deviate as far from the authentic n64 controller OSContPad
as the port would like. This would allow for a port to create an OSContPad
structure based on in-game actions, for example, instead of having
libultraship/include/libultraship/libultra/controller.h
Lines 85 to 88 in 883fb45
#define ACTION_OCARINA_A4 0x00001
#define ACTION_OCARINA_B4 0x00002
#define ACTION_OCARINA_F4 0x00004
#define ACTION_OCARINA_D4 0x00008
#define ACTION_ITEM_RIGHT 0x00010
#define ACTION_ITEM_LEFT 0x00020
#define ACTION_ITEM_DOWN 0x00040
this would be very port specific, as each port would know which actions they would want to be able to map (as opposed to relying on original n64 controller mapping to game actions), so LUS wouldn't need to provide any examples or UI for this, just the framework to do so
it's a trivial wrapper, we probably don't need it
As of #288 , window size is now persisted through application restarts. On Mac, potentially only on retina screens, this value is not persisted correctly.
When the application is closed, the value stored is double what it should be.
Repro:
Open <game>.json
Set Window.Height
and Window.Width
to 500
Open application and observe it booted with the correct width/height.
Observe value in json file has not been touched.
Close application
Observe value in json has been doubled
Re-open application and observe the width/height is now double what it should be
"I should be able to map/configure my controller(s) intuitively."
"I should be able to get up and running without building my own controller mapping/configuration menu"
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.