Linux build broken for 13 days now about adadoom3 HOT 20 CLOSED

I fixed some issues but there are still some build errors. This is caused by a more fundamental issue of excessive (sub)typing in https://github.com/AdaDoom3/AdaDoom3/blob/master/Code/neo-foundation-data_types.ads What is the reason to not simply use the already provided types?

from adadoom3.

I like the readability of the renaming the data types, its really helpful for me to see the byte size

from adadoom3.

Confirmed fixed:

http://46.148.150.105:8080/job/AdaDoom3-linux-x86-64/152/

Thanks charlie5

from adadoom3.

You're welcome ... :).

from adadoom3.

hello charlie5 thanks for the contribution!

kensan, what other downsides do you see to my renaming of the data types?

from adadoom3.

Since there are so many new (sub)types, the code is harder to read/understand for people that are new to the project. Effort is required to to get to know all the new types, which steepens the learning curve.

from adadoom3.

Do you think a "Getting Started" section in the read me that described the design a bit would reduce the learning curve?

from adadoom3.

"Getting Started" will definitely help with learning curve.

from adadoom3.

Yes, giving a high.level overview of the source code and the organization of the repository would help. Additionally, the design should be explained/described, e.g. could you described how the platform-specific code is intended to be selected/run?

For instance, there is now POSIX code which is used in a Linux build, but it does not currently work. What is the idea behind all the different platforms and how are they supposed to share common code (i.e. a Linux build having both Linux and POSIX implementations at its disposal).

As a side note, I do not want to discourage you, but in my opinion it would be wiser to focus on a subset of architectures (e.g. Windows and Linux) and get the code base up and running on these two. Otherwise you will divide your efforts by trying to fight too many battles at once ;)

from adadoom3.

Honestly I am really only focusing on the windows build, but I wanted to at least create some empty files with function stubs so other interested people would be able to quickly add functionality (I don't even have a means to test the Linux build atm). I agree, though, getting the entire system layer up before, say, the library would be a bit too much : )

"could you described how the platform-specific code is intended to be selected/run?"
Actually, the implementation system is the next topic I wanted to cover, but do you think I should include other broad design notes in the Design section or in the GettingStarted?

from adadoom3.

A description how the layering/interaction of the platform-specific and the generic code is intended to work would be beneficial. I currently do not see how Linux and POSIX are supposed to come together.

from adadoom3.

Ok, for example, a complete implementation has the following files:

system-implementation
networking-implementation
window-implementation
memory-implementation
opengl(loading)-implementation
openal(loading)-implementation
processor-implementation_for_os
text-implementation
input-implementation
and exception_handling-implementation

But because POSIX commands are supported on both mac and linux it is possible to reduce the overhead of their implementation by using as much cross-platform code as possible, so the these files can be implemented and included by both of the OSes with no need to create a custom version for each

network-implementation (BSD sockets)
system-implementation (POSIX system calls)
memory-implementation (POSIX system calls)
processor-implementation_for_os (POSIX system calls)

This is why these files are left out of the Linux and Mac folders, because the linux and mac implementation rely on POSIX for them. POSIX is not a fallback or duplicate of functionality between the two OSes, it is a requirement to complete the functionality. The rest of the files require specific knowledge of the OS or windowing system such as X11 or Cocoa

The original doom3 code release did something very similar too
https://github.com/id-Software/DOOM-3/tree/master/neo/sys

The other folders are for different cpu architectures (processor-implementation_for_arch) -- x86-64, ARM, PowerPC -- or for compiler stack traces (processor-implementation_for_compiler) -- GNAT, ObjectAda.

...I will make a better write-up of this and include it in the design section

from adadoom3.

Hi folks,

Just a quick word to say hello and nice project :).

I'm a bit pressed for time, atm, so can be a bit tardy in replies and contributions :/.

I've been toying with Ada and games for some time, trying to get together a set of useful Ada libraries for online games and sims. I especially like DSA (Annex E) and have mucked about with it a bit. Other areas of interest are physics (bullet port to Ada, amongst other engines) and graphics (openGL using shaders mostly).

The bad news (for me ;) )is that the code is still prototype ie buggy, poorly or lightly documented and largely untested :/. In any case, it would be wonderful if any of these libraries could be of use to AdaDoom.

regards,
Charlie.

ps I'll try to be more active in future discussions.

from adadoom3.

hello charlie and thanks again for the interest. I have actually done hardly any graphics programming and definitely have never done shader code so its nice to have someone on board to help out in this area.

bullet would make a great addition to the project, but I would still like to implement the physics from id-tech -- so an abstraction would be required. I understand very little of the distributed systems annex, does it rely on someone else's socket code to work, or is it possible to write your own?

"The bad news (for me ;) )is that the code is still prototype ie buggy, poorly or lightly documented and largely untested :/"
"Real Programmers don't need comments-- the code is obvious" :P. Jokes aside, I do plan on documenting, but right now I am in too much of a hurry to finish the system layer and the design is still evolving

Edit: I have decided against using the DSA, not only is this creating a large dependency most implementations rely on GNAT-sockets which is not portable to different compilers and isn't even fully task safe (see function Get_Host_By_Address) https://www2.adacore.com/gap-static/GNAT_Book/html/rts/g-socket__adb.htm

Edit 2: Looks like I misread the gnatsocket source, it is task safe. still, stuff like polyorb is a little too large for my liking :/

from adadoom3.

Hi again,

"The code is self documenting" -> my favourite excuse ;).

Um, I think my comment "the code is still prototype" was a bit ambiguous perhaps. I meant the code I've been working on is prototype (ie I wasn't calling AdaDoom buggy, poorly or lightly documented and largely untested).

Anyways, will be looking forward to any news and progress ... :).

from adadoom3.

Sorry about that, but as soon as I read "poorly or lightly documented" I couldn't help but think about my project lol

Yes, I am hoping to have the system layer for windows complete by the end of summer so stay posted :)

Edit: Could you post a link to your ada code? -- I would love to have a look

from adadoom3.

Sure. Here is a link to the Lace wiki ...

  https://www.assembla.com/wiki/show/openada/Lace

The project is undergoing something of an overhaul atm. Only the base tier (containing event and math components) is in the public Assembla repo. I plan to add higher level tiers (graphics, physics in tier 2 next) back in over the next few months. In the base tier, the events component is starting to look reasonable, tho the math one needs a lot of cleaning up.

Heh, finally, please bear in mind that the code is still largely prototype ;).

from adadoom3.

Very impressive, it looks like you are in the process of rewriting bullet 3d completely. Would you be interested in porting your math code over to adadoom3's library?

https://hg.assembla.com/openada.5/file/9affed11838d/source/math

from adadoom3.

Heh, yes, a large part of the effort was in the bullet3d port. The hope is to tidy the codebase, make it more Ada-like and make use of Ada's tasking if/where possible.

Sure, I'd be happy for the math component (such as it is) to be used by AdaDoom. Do you prefer copying the source files directly in or adding a small script which pulls in Lace as a mercurial repo ?

from adadoom3.

Thanks charlie

"Do you prefer copying the source files directly in or adding a small script which pulls in Lace as a mercurial repo ?"
I don't mind either way

from adadoom3.