Closed dashodanger closed 3 years ago
This is beyond great! The timing is impeccable; I just received my first Raspberry Pi (Canakit Pi4/4GB), so this is very exciting. 😀
Being a newcomer to that though, I'll have to setup a compile environment to test (hopefully MSVC can be utilized, or at the very least GCC/Debian). I am looking forward to seeing what optimizations you can introduce as progress is made!
How would you prefer collaborating on this port? Post issues here or at your fork's Git?
I don't mind checking your repo for issues...I'm glad to learn more and try to help out with EDGE, but my main line of effort these days is the Obsidian (OBLIGE fork) map generator, so I may not be able to address things as quickly as you might like. I've found that EDGE performs far better than LZ/GZDoom due to its support for older OpenGL rendering, and the gameplay mods I've tried seem to lend themselves well to random map gen, so I thought I'd get it working with Obsidian.
Should I start by poking around the current issues in the tracker?
-Dasho
From: Corbin @.> Sent: Sunday, May 9, 2021 10:06 AM To: 3dfxdev/EDGE @.> Cc: dashodanger @.>; Author @.> Subject: Re: [3dfxdev/EDGE] Basic support for Pi 4 B/AArch64 (#80)
This is beyond great! The timing is impeccable; I just received my first Raspberry Pi (Canakit Pi4/4GB), so this is very exciting. 😀
Being a newcomer to that though, I'll have to setup a compile environment to test (hopefully MSVC can be utilized, or at the very least GCC/Debian). I am looking forward to seeing what optimizations you can introduce as progress is made!
How would you prefer collaborating on this port? Post issues here or at your fork's Git?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2F3dfxdev%2FEDGE%2Fpull%2F80%23issuecomment-835835370&data=04%7C01%7C%7C15d0324098dd45d0bdf508d91304795d%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637561732193707614%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=py1d2a24VzPNupJi6fUnWzqUD%2Bxh%2FH%2F4WC%2Bda8CJE8Y%3D&reserved=0, or unsubscribehttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAN6TJDBK4TIW3ZYYV4VRDC3TM2XKFANCNFSM44O4OUTQ&data=04%7C01%7C%7C15d0324098dd45d0bdf508d91304795d%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637561732193707614%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ht6zGGLjD%2FnY3qdSoVlCn61jyIgwniCtPiiXTfPf44w%3D&reserved=0.
No worries! :) You might have a slight advantage when it comes to EDGE because Oblige, as we know, was originally developed by my predecessor (hence, coding style is much the same). You might see some Oblige code here and there, that was meant to replace some things in EDGE but never happened at the time.
I'm glad to hear that EDGE runs a lot better. The rendering systems are all in flux however, due to the fact that we decided to keep the old rendering path while integrating a more modern GL3-based version (which is why the new path still uses immediate-mode calls - it is still unfinished, which the cvar 'r_gl3_path' controls). But decisions like having 3 different shader subsystems (for example) makes things a bit more complex at times.
Finally, the issues there in the Git listing, are mostly 'generic' with the exception of a better IWAD/PWAD/MOD handling system that EDGE desperately needs. Aside from just general utility/backend functionality, a much more representative idea of issues that need to be looked at can be found at the EDGE forums:
Compiles and runs, but have not touched optimizations or CMake flags