Still supports DOS/Watcom?

[hydexon]

Hi, i want to know if this fork kept the DOS and Watcom compatibility knowing the OG source code releases are really tough to rebuild unless i want to use the old Watcom prebuilt libraries.

I can integrate it with Allegro 4.2.2 without much issue, to implement the required functionality for DOSGfxBegin/End and alikes if needed.

[vs49688]

Hi, no this fork is more focused on modern systems. Most of the real-mode-related code has been completely removed.

I've done my best to keep the code relatively portable (i.e. it should mostly compile), but it expects OS runtime support. Is there an SDL2 implementation for DOS? Otherwise, it shouldn't be too difficult to port the old vesa and mcga drivers.

The software renderer can render to memory-backed pixelmaps (which vesa, mcga, and sdl2dev provide). It's all 32-bit x86 with MMX, so you'll need to manually deal with entering protected mode, etc.

If you wanted to use a software OpenGL driver, beware that glrend requires a minimum of 3.2 Core. Note that sdl2dev can interop with glrend to make things easier (meaning you can create a OpenGL-backed pixelmap via the SDL2 driver).

Also, the internal PE loader has been completely removed, as was a maintenance nightmare. What this effectively means is that BrImageLoad() now defers straight to dlopen() or LoadLibrary(). BDD files can no longer be opened.

If you have code expecting OG BRender, It's probably easier to just port it to this one.

[hydexon]

Thanks for the Response. Sincerely i was surprised that BRender had a Real Mode.

so you'll need to manually deal with entering protected mode, etc.

I believe DOS4GW takes care all of that, unless i'm forgotting something.

Is there an SDL2 implementation for DOS?

The closest you can get as a DOS implementaiton of SDL is Allegro 4.2.2

About the PE loader shouldn't be a concern to me, i could use Allegro 4.2.2 image loading routines instead, and also i'm not interested for the OpenGL driver for now,, i really want to start a new project using BRender that supports DOS and later moderm OS but the original code of BRender is extremely hard to make it work, specially the assembly code which not longer liked by Watcom's Assembler or their forks

Another question is if you kept the fixed point code of BRender too, or everthing is floats?

[vs49688]

Thanks for the Response. Sincerely i was surprised that BRender had a Real Mode.

so you'll need to manually deal with entering protected mode, etc.

I believe DOS4GW takes care all of that, unless i'm forgotting something.

Ahh, of course. I completely forgot about DOS4GW.

Is there an SDL2 implementation for DOS?

The closest you can get as a DOS implementaiton of SDL is Allegro 4.2.2

There's room for an Allegro driver in the source tree ;)

Another question is if you kept the fixed point code of BRender too, or everthing is floats?

Everything's floats, the fixed-point code was removed during the great ASM purge. I'd gladly accept a rewrite of core/math/fixed386.asm in C.

[hydexon]

Before i take a gamble on revive DOS/fixed point support back with Allegro and OpenWatcom within this fork, you can tell me what assembly code do you removed?, this is to prevent any future headache i may come across during to the port.

Thankfully some of the Pentium software renderer is still kept the assembly code (probably inactive), and the other software renderer (softrend) is actually has their assembly actually removed, checking that weird real mode assembly is somewhat related to that weird driver plugin system, that one i can keep it out, good riddance.

[vs49688]

The actual rasteriser, pentprim, is active and working, I left all its ASM intact. For the "renderer", softrend, I've replaced most of it with C. All of this is fully working, but only using 32-bit MSVC. See softcube16.

The fixed-point ASM in math was removed.

Basically, I'd like minimal/no ASM in core. In drivers, it's fine, but I'd still prefer to keep it to a minimum.

On 12 May 2023 2:54:34 pm AEST, hydexon @.***> wrote:

Before i take a gamble on revive DOS/fixed point support back with Allegro and OpenWatcom within this fork, you can tell me what assembly code do you removed?, this is to prevent any future headache i may come across during to the port.

Thankfully some of the Pentium software renderer is still kept the assembly code (probably inactive), and the other software renderer (softrend) is actually has their assembly actually removed.

-- Reply to this email directly or view it on GitHub: https://github.com/crocguy0688/CrocDE-BRender/issues/29#issuecomment-1545131253 You are receiving this because you commented.

Message ID: @.***>

[vs49688]

Oh hang on, I just remembered that I removed the fixed-point methods from the DDI classes.

Hmm, let me have a think about how this would work 🤔.

On 12 May 2023 2:54:34 pm AEST, hydexon @.***> wrote:

Before i take a gamble on revive DOS/fixed point support back with Allegro and OpenWatcom within this fork, you can tell me what assembly code do you removed?, this is to prevent any future headache i may come across during to the port.

Thankfully some of the Pentium software renderer is still kept the assembly code (probably inactive), and the other software renderer (softrend) is actually has their assembly actually removed.

-- Reply to this email directly or view it on GitHub: https://github.com/crocguy0688/CrocDE-BRender/issues/29#issuecomment-1545131253 You are receiving this because you commented.

Message ID: @.***>

[vs49688]

Okay, I've had a think about things:

• On adding C implementations of the BrFixed*() functions - I have zero issues with this, they're part of the public API. This should probably be done regardless.

• On restoring the rest of the fixed-point functionality, I'm a bit apprehensive about it tbqh. It's a whole bunch of extra complexity to maintain, and it effectively doubles the number of build combinations.

  The engine builds and runs fine as floating-point. Assuming they're using the public API, applications don't need to care. Floating or fixed is purely an internal change - the engine simply invokes different methods in the drivers.

  The only driver that implements fixed-point rendering is pentprim, and even then those parts are #ifdef'd out. pentprim fully supports floating-point rendering (see examples/softcube16).

  Do you really need to run this on systems without floating-poing support? I'm not sure of any systems (except maybe some embedded ones) that don't have floating-point support these days.

  Have a look at https://github.com/crocguy0688/CrocDE-BRender/tree/fixedrestore to see what I mean.

• On restoring Watcom support? Do you mean OG Watcom, or Open Watcom? How good is it's C99/C11 support?

  I already purged these disgusting things, I am loath to restore them:

  /*
  * Entry/exit tracking hooksfor Watcom C++
  */
  void BR_RESIDENT_ENTRY _EPI(void);
  void BR_RESIDENT_ENTRY _PRO(void);

[hydexon]

well, i don't blame you, code from the 90s is horrific from the modern developer eyes they had to do the job with what they had in hand. I've studing of restoring BRender 1.3.2 using OpenWatcom v2 + UASM (MASM compatible replacement) and CMake, but the arcane DDL driver system as well the annoyance of generating include files for the assembly files from the C headers making a total chore.

Fixed point that could be a tad problematic since it can lead to several variations of the software renderer builds. yeah i should investigate further, doing it from the 1.3.2 sources it feels a just a waste of effort, specially getting rid of that ancient BDD driver interface code.

OpenWatcom v2 has somewhat decent support for C99 (you need specify a compiler flag to enable it, otherwise is stuck to C89),non-existent for C11, btw _EPI and _PRO are special compilern markers to generate profiling info for Watcom profiler sampler tool, no idea why BRender decided to mess around with them.

I was hestiant about the fixed point support since i wanted to aim my project to the lower end x86 CPUs like the 386DX-40 and the 486DX2-66, where their FPU units are weaker and slower, but seeing the complexity of returning it back, i decided to go explore other options for my DOS rendering needs (Small3dlib or TinyGL), and take a look to this fork again, probably i'm going to make a personal fork with attempts of restoring the fixed point and DOS support.