spinout

Try a different optimization level. What one are you currently using? -O3 / -O4 (if your compiler has it) might be too heavy, try -O2 or -Os.

I have a grey 1.0 cart as well. I will purchase (and dump) this cart if you guys could help pay me back over time...

That is my old outdated Yaz0 compressor. The one mentioned in the first post is something completely different. Please be familiar with my software before saying it doesn't work (and takes 5 hours, it takes less than a minute with LZO compression). The one in my video (the one Gazpacho146 mentioned in his post) compresses to under 32 MB, because it uses LZO compression. I have tried the compressed ROM on actual hardware; it works flawlessly. Here is a link to the patch you need to apply to your ROM (ppf, this was before bps mind you), and a compiled Win32 compressor. The readme doesn't have carriage returns so read it in anything but notepad. http://spinout182.com/ar/z-filenew-windows.zip

...Unless you match collision to mesh using the given buttons.

devdevdevdev

semi-related: http://64.vg/src/c9b6ce6071c84b8ed03b5844ea80632d

What about a good 'ol N64? Why must we make emulated software work with bad emulators instead of making good emulators? Use another video plugin. Use Nemu64. Use Mupen64plus. Use a 64drive or an everdrive 64

If the problem is decoding and generating strings fast enough, you might want to consider making an array of pointers to strings of disassembled opcodes, the opcodes themselves being array indicies.... but that might not be the problem you're having, just throwing it out there.

I don't know if it's possible to use C libraries in C#, but if so I think libobj would be a good place to start, especially now that the [working] functions can segregate by whatever means you want - that is, organize by mesh, group, object, smoothing group, whatever. And I'm sure you would have useful contributions to backport to the library if you did use it. In regards to libobj n64 mesh generation, I'm working on a separate library which will do texture conversion, because as of current it only does 5551 non-CI. Of course, the active version of libobj isn't the main libobj repository; the main libobj repository is still compatible with z64anim whereas the new one requires libmem32. I don't know how well applications end up being with libmem32, I haven't implemented it in z64anim yet. Sorry for going off topic [ and into my own software ], carry on...

Yeah man

0x0F command in scene header. http://wiki.spinout182.com/w/Maps_and_Scenes#Environments_list

Steps 1 and 2, while both contain essential knowledge on how to use many of my other similar hacks/programs, can technically be avoided by creating a patch with the hack but without any usage of it. That being said, I totally think this is a great idea.

I always like to see that some of my more obscure projects get used

It is a very good film - good enough to pay for, in my opinion. Do note that I only pay for 25% of the movies I've seen and the rest are shared without charge [tbp!]. I like how it has such a weird clash of culture.

Los Vegas? I think it's Las Vegas. The theme of your content isn't quite my interest, but the site itself looks clean. You manage to get a lot of stuff while keeping it clean, a phenomena which too many sites both large and small seem to suffer from.

It would be interesting if this topic got locked before 50 posts. Eating cinnamon power is nothing. Just a little woody

Excellent work thus far, this will prove to be a great resource with time.

0x80211174 - This address is for all actors - including link. You'll have to go about "freezing" other actors another way.0x8002F828 - this is the function that plays sounds. Breakpoint it to get the arguments.As for another way to freeze actors, I would suggest perhaps modifying the logic which executes actor code. Actors, when running, have two chunks of code which are executed: logic and visuals. Execute logic only, they will be invisible, and execute visuals only, and they will stay still. I'm not sure on the details, but whatever parses the array of double linked lists of actors (http://wiki.spinout182.com/w/Actors#Loaded_Actors see "At 0x80213C50 within RAM..." ).If needed, give me a RAM dump with a few different kinds of actors loaded and I will analyze it and provide you with an example of how it works if the article I provided isn't sufficient.

I didn't thoroughly read this topic, but you can usually trash $ra after the first few instructions because most functions produced by C compilers put $ra in the stack pretty quickly. When those functions return, so long as you didn't trash the stack pointer, they will successfully recover the return address from the stack.

Scene numbers can be found here, Katz: http://spinout182.com/mqd/s.html OR http://wiki.spinout182.com/w/Zelda_64_Scene_Listings:_Debug_ROM I'm looking forward to the development of this stuff.

same :|

z64anim isn't [yet] updated to work with libmem32 and my new forks of libbadrdp and libobj, as they themselves are completely unstable. I encourage anyone with the time and resources to do any work to fork my code and hack as you please, I will probably include your code if it doesn't break anything. I'm just too busy right now - 4 days of work, 3 days of [full time] school.

1984?

> When I read the topic title http://spinout182.com/steam2011 > When I read the first post Probably z64anim and all the work I have done on the libraries which support it.

You know, I think that the coordinates are being converted wrong, as the texture can be corrected as JSA said. A few test cases are surely needed.