I'm digging into cen64 code right now and was thinking about adding a renderer over it (don't expect anything, just a hobby project). I have few notes to share. Do what you want with it.
In it's current state, cen64 currently need OpenGL for windows rendering purpose. So for now, the OpenGL code cen64 use is tightly related to angrylion implementation (of course, it simply render a texture pointing to the buffer rendered by angrylion code).
If you want to create your own video backend (OpenGL, Vulkan, DirectX, whatever) you have some modifications to do.
First, remove angrylion references:
Rename angrylion_rdp_init(device); in device.c/create_device() to your own. gl_rdp_init(device) in my situation
Then modify current OpenGL-for-angrylion code with your:
Change gl_window_* in vi/render.c that are related to angrylion implementation. For example, gl_window_init() is called inside vi_init().
If you want to support more than one renderer, you have to write a common interface. Roughly I see this:
Mandatory *_rdp_init(device) and *_rdp_close(), run only at rdp setup.
*_rdp_process_list(), for RDP emulation
And window behavior *_window_init(device), *_window_render_frame(device), etc.
If we use aio for AngryLion, this would give aio_rdp_init(device), aio_rdp_close(), aio_rdp_process_list(device), aio_window_init(device), etc.
For OpenGL, replace aio to gl, etc.
The main problem I see with this is the windows management (we have the same problem with mupen64plus). What about non GL context windows (Android, Vulkan, GLES, future api, etc.) I don't know how Dolphin team is managing this.
Anyway... I know RDP is not the bottleneck for now so don't worry about this, I'm just having fun with code.
Discuss topics related to development here.
1 post • Page 1 of 1
Who is online
Users browsing this forum: No registered users and 2 guests