N64 programming (libdragon)

Discussion of development of software for any "obsolete" computer or video game system.
Posts: 1276
Joined: Tue Oct 06, 2015 10:16 am

Re: N64 programming (libdragon)

Post by calima » Fri Oct 20, 2017 10:45 am

The latter has a vertical line on top of the island, looks like misaligned texcoords.

Posts: 25
Joined: Thu May 25, 2017 7:27 am

Re: N64 programming (libdragon)

Post by BMBx64 » Sun Nov 19, 2017 10:16 am

calima wrote:The latter has a vertical line on top of the island, looks like misaligned texcoords.
Yeah you are right, im not sure if it was a mistake on the emulator, on real harware seems fine.

Another color combiner, provides some kind of TV noise, works on rectangles and triangles, added 2 options.

1) Partial

2) Complete

The last one is compatible with RGB scale and alpha, so you could replicate the interferences of the Goldeneye watch for example.

I believe is pretty similar to some special effects of Sin & Punishment, like on the evade move, some emulators wont replicate this effect.

Here can be seen better, however the dots are transparent instead of black, i will keep researching..


I have changed the way some function works, now you can set 1CYCLE or 2CYCLE with:
- rdp_texture_cycle( num ); // 0 = 1cycle, 1 = 2cycle

However 2cycle still doesnt works, but will be useful when 3D is added.

Other functions such as:
- rdp_additive_blending
- rdp_intensify
- rdp_color
- rdp_noise

Has been improved, previously you could call them without setting RDP to 1cycle, but they did a call to set other modes for that, in 3D i believe most of the time the RDP will be in 1cycle or 2cycle mode, so now they just do a color combiner set and must be called after setting the RDP into cycle mode.

User avatar
Drew Sebastino
Formerly Espozo
Posts: 3503
Joined: Mon Sep 15, 2014 4:35 pm
Location: Richmond, Virginia

Re: N64 programming (libdragon)

Post by Drew Sebastino » Sun Nov 19, 2017 2:02 pm

I'm really loving all the niche effects that you're adding. :lol: Honestly though, that second gif makes it look like it could be useful for water splashes or shattered glass or something of that nature.

Posts: 363
Joined: Sun Nov 23, 2014 12:16 pm

Re: N64 programming (libdragon)

Post by Erockbrox » Mon Dec 04, 2017 1:53 am

So I'm reading this thread and trying to understand what everything is here.

Is this a game engine that you are making for the N-64? Or is there a programming library for the N-64 called libdragon and you are just developing code with it to create cool special effects that can be used by a homebrewer to make new N-64 games?

Posts: 25
Joined: Thu May 25, 2017 7:27 am

Re: N64 programming (libdragon)

Post by BMBx64 » Mon Dec 04, 2017 12:07 pm

Yeah a bit of both things.

Libdragon is a library for programming on N64, however is really limited, at the point sprite flip was not even possible, so ive started improving it/adding new features.

Then i made a tool for converting textures and a tile engine.

Im moving soon to libn64, the lib of Marathon (author of CEN64), im working with Krom to port most of the RDP features to libn64, we have a rdp.c for all the internal RDP calls and rdp_functions.c for more user friendly functions (libdragon style).

Krom is working on the 3D lib which will be pretty cool, right now all the math is done by the CPU and drawn by the RDP, once everything is ported and its stable will be moved to the RSP for more speed.

Libn64 is pretty fast and have thread support.

Regarding libdragon ive done some fixes.

A palette can be selected now from 0 to 15 on 4bit textures using:
rdp_select_palette( uint8_t pal );

Textures of 64x64x4bit can be used now (full 2KB), for some reason when the texture takes 2KB overwrittes the TLUT area, and the texture won't show, however if we set palette 2 or higher that data remains untouched.

This makes the trick (edited..):
uint16_t palette_0[16] = { 0,16641,33553,42009,25369,16913,25097,8449,50465,34089,25633,17177,8721,769,513,265 };
rdp_load_palette(2,15,palette_0); // upload starting TMEM on palette 2, 16 colors upload (0-15), point to the palette struct

This function can upload individual palettes.

I did once again a Goldenaxe scroll test but this time with 64x64x4bit textures.
x= 0 - 232 fps
x= 194 - 212 fps
x= 974 - 204 fps
x= 1552 - 222 fps

I think if all the textures shares the same palette this could be faster than a 64x32x16bit texture, both are very close in terms of performance.

DOWNLOAD (64x64 test)
https://mega.nz/#!ZkhVRb7K!UejX0KrNIPeK ... u5heYgGLDU

Some functions has been renamed using the internal names of n64 or has been changed to match the work done on libn64 for easier code migration.

As for example all these functions:
rdp_enable_1primitive(1); // enable
rdp_enable_1primitive(0); // disable

Works like this:
rdp_texture_copy( ATOMIC_PRIM | EN_TLUT );

Or if you dont want to enable anything else than copy mode, this overwrittes the previous command:

The define list for the 64bit commands comes on the examples of Fire & Tlut on github, but i could provide a more detailed one if anyone is interested.

Examples and lib has been updated on github:

User avatar
Posts: 1352
Joined: Sun May 27, 2012 8:43 pm

Re: N64 programming (libdragon)

Post by mikejmoffitt » Fri Dec 15, 2017 11:39 am

You should make a pull request against the master libdragon repo for your changes.

Posts: 25
Joined: Thu May 25, 2017 7:27 am

Re: N64 programming (libdragon)

Post by BMBx64 » Wed Oct 31, 2018 8:55 pm

Hi, since libn64 is taking a while i decided to take another look at libdragon and fix, clean, add new content.

There was a bug when disabling AA (320x240) on NTSC, at first i though it was a libdragon fault but when setting 0x00003302 directly to VI status the bug remains, seems like a bad combination that the hardware dislikes, so the more closer solution is 0x00003202 (AA RESAMPLE).

Added load_sprite, this function load textures from the cartridge and takes care of the CPU cache, it writes back to the RAM, so the RDP can draw them properly.

Flush_strategy is pointless now and was removed, when enabled this function was intented to write back to RAM each time a texture was loaded on TMEM instead of only once (when loaded from the cartridge), if a texture data have to be changed on the fly data_cache_hit_writeback_invalidate can be used.

Lib and examples on the same place:

Sorry mikejmoffitt i missed your message :oops:

Post Reply