ZDoom

HxDoom. The Haxelib adaption of id Tech 1 that can go anywhere and be used by anyone!
https://github.com/kevansevans/HxDoom

////////////////////////////////////////////////////////////////////////////////////////////////////

The goal of HxDoom is to create a cross platform library that can be used to make Doom related programs with. The language HxDoom is being built with is Haxe, a cross platform toolkit and language built with singular source cross platform deployment in mind. Wherever Haxe can deploy, HxDoom must do the same! This, however, does not mean any projects using HxDoom as a library have to abide to this.

Advantages this will provide:

- Users will not need to fork someone else's code to maintain parity.
- Less susceptibility to playing catch up for when new features are implemented.
- Cross platform deployment from the get-go without having to make different branches of ones source.
- Projects using HxDoom are not required to make their projects open source (But you really should make them open anyways).

////////////////////////////////////////////////////////////////////////////////////////////////////

Looking to recruit!

Yes! Applications to help with the project are now open! I'm not sure what sort of requirements I'm looking for, but obvious programming experience is a must, and willingness to work with a semi-niche programming language is needed as well. Or if you just want to make some quick fixes/contributions and make pull requests, that's welcome too!

kevansevans wrote:Golly I think I'm ready to share this project here, some of you have saw me talk about this on the Discord though.
Citrus Doom is what's going to be playable. In order to make sure that zero game logic ends up outside of HxDoom, I am keeping this half of the code under a separate repository. Citrus Doom gets it's name from the Haxelib it's being built upon, which is called Lime (Light, Integratable Media Engine). Lime primarily exposes several rendering pipelines, and I'll be taking advantage of that to demonstrate HxDoom's ability to function under several targets. As of now, there is no software rendering code. That might come later as either an Adobe Air app (Again just for demonstration purposes), or utilizing the Cairo exposure. Not a fan of Cairo, but it is a software rendering library. The hardware rendering code that's being used is on WebGL. This may seem confusing at first, but Lime has the ability to take WebGL and convert it to GLES2, and or OpenGL. So while targeting desktop, the rendering pipeline will utilize OpenGL/GLES calls, and on web, WebGL calls (WebGL2 has yet to be supported as the Lime developer is having issues binding to GLES3 which is needed to maintain WebGL2 -> GLES -> OpenGL).

So in laymans terms: Lime is a translation layer that provides the developer with a set of several pipelines that make it usuable to work on different platforms. Something similar to SDL, but more focused on rendering paradigms.

The reason for that summary is because i think most users likely have no idea what most of this means (And by my summary, i also may not know what it means if it contains errors, lol). I knew of HXDoom before, but back then it was a clear port. Now its a library that Citrus uses. (This is how i understand it).

Personally i think such a cross-platform approach (One codebase that can deploy to oodles of platforms) is an interesting one. Something like Unity, but purely for a Doom Engine. I mean, that's exciting stuff. And because the whole thing is open source, it could be a good base port aswell (Where now Linux Doom/Chocolate Doom and PRBoom are the primarly stepping stones from which most platform ports by people are based upon).

kevansevans wrote:Trying to get down the ability to mimic the original behavior, where once the screen is filled horizontally and what not, but no luck so far. Lot of the code I have written was pulled from here: https://github.com/amroibrahim/DIYDoom which borrows a lot of code from Chocolate doom. Not quite a source port as I'm only following instructions, but for the sake of transparency, I'm putting this here so I'm not yelled at for not crediting my sources.

If you want another ''DIY'' approach to look at, here is another one, DJDoom. This one builds it from the LinuxDoom source release instead of Choco. Though DIYDoom is far more extensive, perhaps DJDoom is also useful for you/

kevansevans wrote:Ideally Boom compatible regardless of target. If enough people show interest, I'll definitely start working with them to bring in support for more modern features.

So Citrus as it stands is working towards a complete LinuxDoom 1.10 equivalent that's cross platform, right? Boom compatibility is definitely something interesting, but you can basically go wild: GLDoom's source, for instance. Or how about Doom Classic IOS's GLES renderer that sits on top of a PrBoom based engine? Due to the cross-platform nature, i can see quite a bit of possibilities in here. All that would matter is the HXDoom library.

kevansevans wrote:I hope this is something that sparks interest in the community!

I believe it does, as its definitely a novel idea. However, though you include some nice solid color screenshots, i do think this needs a more profile example for people to understand its usefulness. One idea could be getting that IOS GLES renderer to PC. Or a Boom heavy mod that runs on multiple devices through Citrus.

So conclusion?
It has definitive potential, but it needs a more visible example before i can see lesser tech iterate folks be swayed for this. The concept however is sound.

kevansevans wrote:Some questions people might ask:

Why am I doing this?

1) Learning experience
2) I love making things for other people to use
3) Bragging rights
4) No one else has ported Doom to Haxe

This really is a good enough reason to do it - so if anyone complains about it they can shove those complaints right you know where.

That being said, if this becomes a more fully fleshed out project, it might be interesting to have yet another way to play Doom in various places - i.e. a web browser, yet again.

To show off how my goal for easy porting to other systems, with zero alterations to my current source and after installing the minimum needed environments, HxDoom/Citrus runs on Manjaro. Arch linux confirmed.

Pushed a small update today. latest stable is now 0.0.5-Alpha.

* Improved Core overriding system
* Cleaner map lumps
* Reduced memory usage
* Cleaner implementation of assembling data for supplied renderer
* Dedicated Camera class
* Implemented CVar system
* ZPos getter for all actors, no longer limited to players
* "Closed" Geometry now occludes walls
* "Patch" Reading added hxdoom.lumps.graphic.Patch.hx
* Started samples folder. Requires OpenFL. First Sample is how to read a Patch.

After suffering some burn out and a few weeks considering, I'm now opening up the project to recruiting collaborators. If anyone is wanting to join in on the team and help this project see the light of day, let me know and we can chat.

And would really like some fresh eyes to look at my code, I'm super paranoid over it's readability.

Just today in an effort to test cross deployment, I spent about an hour and a half making a VR test:

https://twitter.com/kbeevans/status/129 ... 72449?s=20

https://imgur.com/4mMkru9
https://imgur.com/Grff9bp

Spoiler:

---

This isn't a "Doom in VR" announcement, but more of a proof of concept at HxDoom's target agnosticism. The VR API being used here is Lovr https://lovr.org/ which is an engine made in Lua, which afaik is one of two Haxe capable targets that can be used to target VR. I have the sample code here: https://github.com/kevansevans/HxDoom/t ... ovr%20Demo

And in case anyone asks, I'm using a Valve Index.

0.0.6 Alpha Release!

https://github.com/kevansevans/HxDoom/r ... tag/A0.0.6

* Significant organization of classes with clearer intent with their names and package paths
* Significant improvements to documentation, friendly to Dox generation.
* Significant overhaul to wad reading and core utilization. Way too much to list!
* Per class dependency injection system utilizing var class:() -> Class = Class.new; Allows for easy behavior replacement of the library without having to rewrite the whole library.
* String parsing for addWad via WadCore.addWadFromString. This is for Haxe targets that do not natively support "bytes" or their filesystem handlers returns strings when reading files.
* Texture reading. Can now read TEXTUREX and PNAME lumps and assemble defined patches.
* Addition of LevelCore.hx which more directly handles loaded maps

This also comes with the announcement of an API website hosted here: https://kevansevans.github.io/HxDoom/api/
This website is generated via the haxelib Dox: https://github.com/HaxeFoundation/dox

Looks like a very interesting project.
I might also be helpful in the future when it comes to development of the suite of programs that are used for editing... both something like SLADE and Doombuilder but also smaller plugins or
tools to help automate many tedious tasks (ie. using 3D models in GZDoom.. I made myself a small commandline utility in c based on some example code for reading MD2 model... my commandline utility reads an MD2 file and spits out a useable modeldef for that file for use with GZDoom modding)

One of the ongoing efforts I've been focusing on is that I want this library to be simple and easy to use. I personally have a hard time reading other peoples code, especially when it's in a language I'm not familiar with. So in an effort to help minimize this for other people who may also have the same difficulties as I do, I've started working on the repositories wiki explaining how HxDoom is meant to be used. I'd really appreciate feedback on this first page I wrote up, which is wad reading basics.

https://github.com/kevansevans/HxDoom/w ... ing-Basics

What I'm looking for is if my explanations make sense to as much possible people reading it. Obviously I won't be able to 100 percent idiot proof it, and I'm not going to hand hold through the whole process. But if someone were to ask "How do I do X in your library", there should be documentation available that explains how and why a function is achieved.

Thank you to anyone offering their time to this!

kevansevans wrote:One of the ongoing efforts I've been focusing on is that I want this library to be simple and easy to use. I personally have a hard time reading other peoples code, especially when it's in a language I'm not familiar with. So in an effort to help minimize this for other people who may also have the same difficulties as I do, I've started working on the repositories wiki explaining how HxDoom is meant to be used. I'd really appreciate feedback on this first page I wrote up, which is wad reading basics.

https://github.com/kevansevans/HxDoom/w ... ing-Basics

What I'm looking for is if my explanations make sense to as much possible people reading it. Obviously I won't be able to 100 percent idiot proof it, and I'm not going to hand hold through the whole process. But if someone were to ask "How do I do X in your library", there should be documentation available that explains how and why a function is achieved.

Thank you to anyone offering their time to this!

I have kept this post on tab for the last few days and will do so here aswell - Eventually ill give it a look and provide some feedback, Kevans!

Redneckerz wrote:I have kept this post on tab for the last few days and will do so here aswell - Eventually ill give it a look and provide some feedback, Kevans!

Golly gosh, looking forward to it. Been really needing some fresh eyes on it.

kevansevans wrote:

Redneckerz wrote:I have kept this post on tab for the last few days and will do so here aswell - Eventually ill give it a look and provide some feedback, Kevans!

Golly gosh, looking forward to it. Been really needing some fresh eyes on it.

Ill put a word in advance - My code reading skills are very limited. But enough to spot obvious signs. Keeping this idling and ill get to it - Somewhere.

https://github.com/kevansevans/HxDoom/r ... tag/0.0.7A

So awesome update for today, the library is now MIT and I'll now be using MIT/Blackbox only sources! I'll be using source code found in the release of the 3D0 version of Doom, which is MIT: https://github.com/Olde-Skuul/doom3do

Changes:

* The Haxelib is now MIT!
- A sizeable chunk of the previous in-dev work had to be removed due to it being borrowed from GPL2 sources. This is counter to the goals of HxDoom. A substitute source has been found and will be used from now on.
* Flat textures reading added.
* Blockmap reading added.
* Dependency injection for functions added to Reader.hx.
* Vanilla maps can read out of order lumps.
* Further fixes to wall visibly calculations.
* Sector.hx
- Added 'lines' array that stores all linedefs that make up sector.
- Added 'getSortedVertices' static method that returns a correctly sorted array of vertices, meant for aiding with converting map geometry into GL-Esque friendly data.
* General code cleanup