Adding Opera (3DO) as emulation core in Bizhawk #4264
Conversation
waterbox/opera/bizhawk.cpp
Outdated
| ECL_EXPORT bool sram_changed() { return _nvramChanged; } | ||
| ECL_EXPORT int get_sram_size() { return NVRAM_SIZE; } | ||
| ECL_EXPORT uint8_t* get_sram_buffer() { return (uint8_t*) NVRAM; } | ||
| ECL_EXPORT void get_sram(uint8_t* sramBuffer) | ||
| { | ||
| if (NVRAM == NULL) return; | ||
| memcpy(sramBuffer, get_sram_buffer(), get_sram_size()); | ||
| } | ||
|
|
||
| ECL_EXPORT void set_sram(uint8_t* sramBuffer) | ||
| { | ||
| if (NVRAM == NULL) opera_nvram_init(NVRAM,NVRAM_SIZE); | ||
| memcpy(get_sram_buffer(), sramBuffer, get_sram_size()); | ||
| } |
There was a problem hiding this comment.
For some reason retro_get_memory_data does not seem to expose this NVRAM (via RETRO_MEMORY_SAVE_RAM for example) but perhaps that would be the better place to expose this to instead of writing an own function for it.
You could then also expose this NVRAM as memory domain with the MEMORYAREA_FLAGS_SAVERAMMABLE flag and I believe the frontend will then automatically handle saveram for you.
waterbox/opera/Makefile
Outdated
| -DINLINE=inline \ | ||
| -DTHREADED_DSP | ||
|
|
||
| CXXFLAGS := $(CCFLAGS) -std=c++20 |
There was a problem hiding this comment.
Is this just for the bizhawk.cpp? Might be easier to just make it a normal .c file and get rid of all the cpp handling.
There was a problem hiding this comment.
I do use std::string in bizhawk.cpp. It is much cleaner than C-style string manip. But I removed the c++20 and cleaned things up
src/BizHawk.Emulation.Common/Base Implementations/Bk2MnemonicLookup.cs
Outdated
Show resolved
Hide resolved
waterbox/opera/bizhawk.cpp
Outdated
|
|
||
| void RETRO_CALLCONV retro_input_poll_callback() | ||
| { | ||
| _isLagFrame = false; |
There was a problem hiding this comment.
retro_input_poll is completely useless in figuring out lag information. It is simply a callback that tells the frontend that the core wants input updated, which in practice is something that happens every single retro_run call regardless, making it fairly redundant in the libretro API. It is not a callback that tells the frontend that the game is acquiring input (i.e. actual non-lag indication). You cannot rely on libretro handling lag information for you, BizHawk code must have its own implementation for that.
|
|
||
| private readonly List<IDiscAsset> _discAssets; | ||
|
|
||
| private string GetFullName(IRomAsset rom) => rom.Game.Name + rom.Extension; |
|
As someone who got the up-to-date build for testing, I may bring some more points:
I think, this might be a good candidate to put in "3DO Controller Configuration" window: https://www.deviantart.com/adrianoramosofht/art/Panasonic-3DO-Controller-2-845186266
|
Thanks so much for the info, I'll get the controller fixed.
The controller pic is nice, though I have no idea how to add it to the Bizhawk GUI.
Afaik .cue images ought to work, but the other devs here should be able to give you a better answer |
|
For controller images we use actual photos. |
Check if completed: