spinout

Only problem is that nothing I can find points to them ;_; Edit: I tested this out some more, DeathBasket was pretty much right: - Areas which can be viewed from the top or normally are black when the camera behaves normally and the JFIF render when viewed from the top - Stores, as DeathBasket said, work fine until you talk to the shop keeper which loads a different background - Castle town main is completely broken, the rest of (outdoor) castle town works fine. Solutions?

xdaniel, any chance of seeing Kd commands implemented? I've (tried) to support them in all my viewers. I *believe* that some GI objects don't even have textures and just use shading to get their color. Edit: DeathBasket, thanks again

The issue isn't JFIF images, but it is something else which is required to render them. I nulled files 961 - 1004 and it broke maps which had their own JFIF images.

I am putting this up so early in development so I can get a sense of weather anybody thinks it is worthwhile to continue. The main issue is that many files have no apparent table other than the DMA table - specifically, files 961 - 1004 (see http://spinout182.com/mqd/f.html). I know very little about sequences and sounds, somebody with more knowledge in that area (DeathBasket ?) would be best for writing the handlers for those tables - see readers.c, writers.c, and tables.c. tl;dr I'm considering halting progress on a tool which is now top priority re: zelda tools because I can't find a pointer to every file. Maybe I should just write a hack for the game itself and re-vamp the whole system. I'd still have the issue of what points to these files, though. Oh, I almost forgot: https://bitbucket.org/ottehr/z64-fm/src

dn = (int)( (nf[0] * p1[0] / 0x7FFF) + (nf[1] * p1[1] / 0x7FFF) + (nf[2] * p1[2] / 0x7FFF) ) * -1; I just realized this could potentially lead to overflow (on 32-bit machines); it would be better written with the division in the middle dn = (int)( (nf[0] / 0x7FFF * p1[0]) + (nf[1] / 0x7FFF * p1[1]) + (nf[2] / 0x7FFF * p1[2]) ) * -1;

Thanks for finding that, DeathBasket. I'll go through everything I can think of that used that code and update it I suppose...

That version uses collision_fixer.exe

It's a bug in the collision code - a bug shared with my importer. Un-check 'show errors' in Nemu and I bet you it'll show an error when you load the map. This is going to be a PITA to fix. ugh.

It only directly supports Master Quest debug at this moment, though 99% of what it produces is compatible with Majora's Mask. Not capitalizing is one thing but this whole pleeeez business is getting to me.

https://bitbucket.org/ottehr/z64-tex-ext - should be ready. I'll try this out as soon as I'm in windows - which should be soon, potentially tonight.

Here is what should be the complete hack - there might be an error or two with the hook; I don't know, I do not have the proper tools to compile and insert it. link. It includes two functions for whoever writes animated texture code, and they are - void * seg_to_ram( int seg ); void set_segment( void *z_ctxt, int seg, void *ptr ); seg_to_ram takes a segment number (0-8, only expect good results with 2,3,4) and returns a RAM pointer to that segment. set_segment sets segment seg to address ptr - z_ctxt is the global context, and the only argument given to the function nested in the map's modified mesh command. Again, games without this hack but with maps designed for it will not crash but the textures will likely be garbage - also known as rainbows. Edit: Back at home for the weekend on a setup more development friendly... https://bitbucket.org/ottehr/z64-tex-ext hehe... Edit: Got it compiled with a working example -

I wrote an entire bytecode interpreter and was writing some example code before I realized it was an oversimplified and limited MIPS. I then removed everything related to bytecode and ended up with this. As far as animating textures goes, switching textures is largely inefficient but having an image that is, say, two rows too tall and increasing the pointer by four bytes every xth frame and then at the end of the image going back to the beginning would produce a scrolling texture without very much overhead. The called functions (in the example I linked to, nested as an extension of the mesh command) would be nested in the map file. It would be up to the users to generate a binary for your program to insert, and you could also have a few 'configurable' binaries (ex: lights going on/off at certain times, scrolling water) included in SharpOcarina.

You should probably say how you solved it and add [sOLVED] to the title so people having trouble in the future can fix the problem. Also, for anything regarding mupen64plus, join #mupen64plus on irc.freenode.net

Well, that sounds like a perfect opportunity to introduce an extension of the scene/map header format - something, for example, which uses the unused bytes of, lets say, the mesh header command - 0Azzzzzz xxxxxxxx - z is normally 0, but in this case, a hack could assume that if it is nonzero that it is to use the bank of x ((x & 0xFF0000000) | z) - and at that point is a simple and extendable bytecode (which SharpOcarina would write) which an interpreter reads to do these custom textures. Games without these hacks would still function perfectly fine, as the game normally ignores the 'z' bytes. I'm sure DeathBasket and/or myself could throw something together.

Well gee it looks like I won't have to write a new map importer - which is probably a good thing, considering how much GUIs and I disagree. I do plan, however, to make a command line tool which will attempt to do an identical import based the generated XML from this application so that *nix people can at least import areas which have been configured with this tool. It would also be rather neat to streamline this stuff in makefiles. As always, excellent work xdaniel.

In the future, you can do .asciiz "string here" instead of .word 0x43... Make sure to use .asciiz and not .ascii as .asciiz automatically puts a '\x00'. I don't have a setup to test it in right now, but from what I'm seeing here, you've done some great work. I hope you inspire others.

Awesome. Always love your hacks, DeathBasket. I don't feel so lonely in this category of hacking anymore

PJ64 has to enable/disable game specific hacks for the games to work. When you change a ROM's CRC, PJ64 no longer enables/disables the hacks, and it runs it as an "unknown" ROM. Try setting the r3400i core to pure interpreter, and setting the game settings correctly. Or use Nemu

What do you mean by that? Putting entries in the file table? If that is what you mean, do realize that correctly using the filetable can require (unless you are lucky) an ENTIRE re-build of the ROM. That means every ROM pointer in code (the overlay, actor, scene, and object tables, I'm sure there are more which aren't even known) - and every pointer in maps and scenes (map pointers, static background JFIF pointers) along with the pointers in the filetable must all be recalculated. Why is this? Because the way OoT looks up files is a binary search - which requires all files to be in order. Sorry for the rant, and if this isn't what you were talking about, :oops:

By the way, what this is is not a DD expansion running - it is the "Error ROM" that every DD disk has at 0x0 which the IPL loads if no cartridge is inserted. You can do it yourself if you stick a 0x1000 byte 6102 ROM header on the F-Zero X expansion and set the entry point (address 8 in the ROM header) to 0x80000400. Twili, if you want to know more about the DD, talk to 'jrra' on irc.efnet.org. He has even implemented some DD features (specifically, DD registers and time) in mupen64plus, and he has lots of information to share with you. He knows the whole LBA thing inside out.

Good times indeed.

64drive, the ultimate n64 flash drive (supports e-v-e-r-y-t-h-i-n-g) is out. I just played Goldeneye:X on the N64 with a friend, using my (beta testing edition) 64drive. http://64drive.retroactive.be/purchase.php \o/

You don't actually have to do a model port, just overwrite another item with the reed whistle's gi:shader combination, as documented on this page. I believe that the reed whistle was to be it's own item, used only to call Epona. Nevertheless, nice work

Very interesting, nice to see someone continuing where JTH left off. What makes you so sure there isn't any model data, and that it is all collision? Are there collision normals of any sort? Also: You do realize you can just do (int)float_var to get an integer from a float, right? There are other tricky things you can do, such as union { uint32_t i; float f; } value;, then value.i = U32(data); (int)value.f;. In n64tool, I made a macro which directly gets floats from data, using a union - union {uint32_t u; float f;} ____u32_f32_union____; /* This variable is ONLY for the F32 macro ! */ #define U32(x) ((uint32_t)( (((uint8_t*)(x))[0]<<24)|(((uint8_t*)(x))[1]<<16)|(((uint8_t*)(x))[2]<<8)|((uint8_t*)(x))[3] )) #define F32(x) ( ( (____u32_f32_union____.u = U32(x)) & 0) + ____u32_f32_union____.f) Note to admins/management: [tt] tags and/or tags with better CSS that don't screw shit up, please and thanks!

Very interesting, nice to see someone continuing where JTH left off. What makes you so sure there isn't any model data, and that it is all collision? Are there collision normals of any sort? Also: You do realize you can just do (int)float_var to get an integer from a float, right? There are other tricky things you can do, such as union { uint32_t i; float f; } value;, then value.i = U32(data); (int)value.f;. In n64tool, I made a macro which directly gets floats from data, using a union - union {uint32_t u; float f;} ____u32_f32_union____; /* This variable is ONLY for the F32 macro ! */ #define U32(x) ((uint32_t)( (((uint8_t*)(x))[0]<<24)|(((uint8_t*)(x))[1]<<16)|(((uint8_t*)(x))[2]<<8)|((uint8_t*)(x))[3] )) #define F32(x) ( ( (____u32_f32_union____.u = U32(x)) & 0) + ____u32_f32_union____.f) Note to admins/management: [tt] tags and/or tags with better CSS that don't screw shit up, please and thanks!