Merge changes upstream?

[awygle]

There's been some discussion in the N64Brew discord (can be found at https://discord.gg/TusxzSN, if you're not familiar) about trying to reduce some of the fragmentation in the N64 homebrew community. Would you be interested in merging some or all of your changes into the original libdragon repo on DragonMinded's discord? Or did you have a specific reason for making this fork that means you don't want your changes to be merged back?

[ijacquez]

Is this the upstream?

If so, all the changes made on this fork should adhere to upstream's original license.

Given how infrequent changes/issues are addressed here, for the sake of de-fragmenting the library, merge the changes to upstream.

[ijacquez]

Here's two from the issues so far:

1. jnmartin84/64doom
2. N64-tools/libdragon

Too much fragmentation!

[networkfusion]

I am happy if the n64-tools version changes that are not part of this fork are merged in to the official libdragon source. I will even help... I am sure that if all of the features above that in conker64's version were also ported he wouldn't mind (depending on libdragons license, might not even matter) or at least would make this fork redundant...

[networkfusion]

From personal correspondence with @jnmartin84 I am also sure he would be happy for any relevant additions to be added to the official version... it just needs a competent person to decide which merge conflicts are correct...

[jnmartin84]

It has been a very long time since I did any active work on 64Doom but I'm pretty sure the only serious changes I made to libdragon were to add an exception handler that printed all register values to the screen for debugging purposes when it crashed. It was a dirty implementation and showed up on real exceptions and on soft reset until the button is released.

About a week ago I rebuilt the codebase from the latest master branch of libdragon pulled from Github and it worked without any changes so there's nothing significant in the way of breaking changes to it.

Take that for what its worth.

[jnmartin84]

The only other change is I had wrappers for memory related functions (malloc/free/memcpy/memset) that I was using to track down memory leaks so calls to those functions in the included copy of libdragon were replaced with "n64_malloc" , "n64_free" etc.

By the time I dumped the Doom code to Github, I had swapped out those wrappers for macros that just #defined them as the original functions anyway.

#define n64_malloc malloc

Etc

[conker64]

Hi, most of the work done on this version its on rdp.c and rdp.h, feel free to merge changes to the official libdragon.

Note that some functions has been changed, renamed or slightly edited due performance or preferences:

• No texture slots, i saw no benefit in 2D, however once 3D happens some functions may need an update to allow more texture formats, mip map, etc
• No flush texture, this should be manual for performance
• No texture stride, slow compared to single texture load in terms of performance, but may have some benefit in loading times (libdragon seems very slow when reading many files from the cart, that needs a fix too)
• Uses unused parts of the .SPRITE struct to save 2D sprite data
• Saves cache for 2D automated sprite management, center align, sprite chain, etc

I may join irc channel sometime and see how goes :)

[jnmartin84]

Turns out I was wrong about the 64Doom stuff. I was linking against old versions even though I built and installed new ones (path issues).

Here is what I had to change in libdragon to get it to build and run again, might be worth nothing:

I didn't want to include my own font data and increase my executable size and memory usage, so I modified "include/font.h" to remove the static modifier from "__font_data" so I could use it for debugging and error messages without calling printf:

static unsigned char const __font_data[2048] = { becomes unsigned char const __font_data[2048] = {

Realistically, I could duplicate this data in 64Doom and there would be no need for a patch to libdragon. The next issue, not so much.

There was an issue with audio buffer sizes not matching what is produced by my sound and music rendering and leading to nasty ticking artifacts, so there was a change in "src/audio.c" to the CALC_BUFFER macro:

#define CALC_BUFFER(x) ( ( ( ( x ) / 25 ) >> 3 ) << 3 ) becomes #define CALC_BUFFER(x) ( ( ( ( x ) / 35 ) >> 3 ) << 3 )

A function signature changed for "get_accessories_present" so I had to change "i_main.c" to add a null parameter to the call to it, but that's not a patch against libdragon. Just mentioned for completeness.

Those changes got it running correctly again.