Opengl 11 texture behavior issues tests start

[meisei4]

I have added some updates that relate to testing i am starting on for models, and am hoping to create the PR in order to tag my current progress. it is not yet finished, but i was hoping to have a stopping point, with some working tests i have added with these changes and these examples:

https://github.com/meisei4/raylib4PlayStation2/tree/main/samples/shapes/cube
https://github.com/meisei4/raylib4PlayStation2/tree/main/samples/models

These also require the state of ps2gl here: https://github.com/meisei4/ps2gl/tree/proper_pvc_no_lights, and partially discussed here: ps2dev/ps2gl#27

[meisei4]

this is a post to address several questions that I’ve had floating in my head. Now that I’ve worked on ps2gl enough to realize it’s likely a project that needs a lot of work — and more than one person (especially a beginner like myself) — I would really like to contribute to raylib4Consoles with any lower-scope nice-to-haves.

Here are some things I thought would be useful:

1. A more coherent project module system

current PROS:

• Build scripts and setup are minimal, and that’s really nice for a release I think, i.e. just run the build script and then you’ve got the samples working.

current CONS:

• The git cloning involves having to keep track of any local experimentation between 3 different modules:
  1. raylib4Consoles/raylib
  2. raylib4Consoles/raylib4<PLATFORM>
  3. <PLATFORM-vendor>/<PLATFORM-opengl-layer> e.g. ps2dev/ps2gl, DragonMinded/libdragon/GL, Kazade/GLdc etc

Ideas I have prototyped:

• Introducing submodules (e.g. https://github.com/meisei4/raylib4PlayStation2/blob/main/.gitmodules) into the raylib4<PLATFORM> project allows for targeting experimental branches for any testing needed to be done on raylib's OPENGL11 front end OR any testing needed to be done on the opengl layer for the platforms

^^ I am not sure if this is the best way, but I believe it would make for documenting the project's dependencies in a much more explicit way rather than having to kind of rely on "installed" system wide modules for when testing end to end with a raylib front end

2. A more navigable project for learning/experimentation

current Issues:

• in the case of ps2gl, the project becomes a hybrid of C/C++, introducing some navigation issues for modern IDEs -- especially for a project that is as OOP-oriented as ps2gl, where there are many inheretance based implementations which requires lots of scattered file navigations
• Navigating and testing iteratively in the projects involves keeping track of a lot of modules, that also need to be rebuilt in all sorts of orders:
  • e.g. if making edits to raylib, one must rebiuld and reinstall raylib to any library location that is expected for -libraylib includes to work. Same goes for any updates to the opengl layer

• rebuilding and installing can cause confusion and just takes a long time when keeping track of any "raylib DESKTOP OPENGL11 < - > raylib PLATFORM OPENGL11" behavior tests

Ideas I have prototyped:

• Introducing compilation database with bear for the C/C++ hybrid nature of ps2gl (This is a very experimental Makefile that i dont think should be merged, it was just the current way i was able to get things working for myself. The core part is being able to define and distinguish what source files should be treated like C, and which need to be treated like C++ in order for IDE navigation and error highlighting to be reduced: https://github.com/meisei4/raylib4PlayStation2/blob/main/Makefile#L26-L27

• In my fork of raylib4Playstation2, when building samples I tried this idea of creating runnable ./main and ./main_ps2 files where ./main targets the DESKTOP OPENGL11 raylib behavior, and ./main_ps2 targets PLAYSTATION2 behavior: https://github.com/meisei4/raylib4PlayStation2/blob/main/samples/models/models_indexed/Makefile#L56 This allowed for easy comparison tests, but it also introduced the need to clean and rebuild raylib to make sure that the object files are DESKTOP vs PLAYSTATION2 built... and so this causes the iteration process to be very slow here...

Anyways, I am wondering if there are any other ideas around the above issues. Or if there are simply any other nice-to-haves that could help further improve this project's structure? I think a lot of my issues with trying to contribute was perhaps related to many of the difficulties with keeping the scope of issues as caused by ps2gl or with raylib itself, and especially with getting closer to the raylib core updates for ps2 (e.g. texture loading and stuff related to opengl indirectly) i imagine it becomes even more difficult to iteratively test and determine where the source of error is. Especially with a not-yet fully fleshed out/working opengl layer such as ps2gl, then the need to integrate ps2 specific behavior into rcore_playstation2.c, and rlgl.h, and other raylib areas

[psxdev]

Right now i have 3 work path in front of me and others work in progress:

1. I have been working with github codespaces lately, for content for a book about raylib and consoles that i am working on. You already know that old console development is a real challenge for newbies without experience in their different toolchains and console platforms, so for that i am preparing codespaces environments ready to use for "newbies" with different console platforms ready to work with raylib4Consoles.

2. We can work in github actions to build for different host and target platforms. We have been doing that with ps2dev and orbisdev in the past. One of the issues that we have is the pain in the ass to sync from time to time from raylib, because raysan and me decided not to commit some console specific code in mainstream to avoid possible issues with some specific console vendors and mantain raylib base code clean of that. So here we have plenty to improve.

3. I am on the way of a pure c gl/gl es implementation for ps2, tryng to solve more than 20 years of technical debt with ps2gl, hard to maitain and evolve to modern ps2sdk. Dreamcast and n64 have an active development group of people working in their gl implentation for years in parallel with their sdks libdragon and kos. We have a "walking dead" ps2gl resurrection a few months ago, and thank to you and some ps2dev people at last we can see more people involved.

It is easier do integration with raylib when we have a gl implementation with good health and stable and with a high compliant level with 1.1 and part of 1.2.

So here we have two options follow working in ps2gl improving/learning how to do things more gl compliant and the other one work in a fresh implementation with modern ps2sdk features. Both options can be done at the same time.

All of these points does not include others that i am working on already in wip status:

1. Improve native pvr and compression textures for dreamcast on raylib4Consoles
2. Add audio integration for different platforms on raylib4Consoles
3. Add native libnfs support for Dreamcast (already did on ps2, vita, orbis and prospero a few years ago)

And at the same time, working in game industry xD, insane you know