xdaniel's Random Junk

[spinout]

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 -

Edited August 28, 2011 by spinout

[xdaniel]

1) Nice video! I guess SharpOcarina support for the hack won't be in the first release, so that I can get it out soon, but it's (hopefully) gonna be supported by the second and source release.

 

2) Said first release of SharpOcarina is probably a few hours or so away, as exit list support is done and working correctly (identical to the object list editor), so all that's left for now is documentation. That's already been started - as you can see a few posts above - but the bulk of it still needs to be written. Tomorrow afternoon at the very, very latest.

 

Edit: 3) Things that won't be in the first release (for various reasons): waypoint support, editing of position/rotation in hexdecimal, the source code, probably one or two other things.

Edited August 28, 2011 by xdaniel

[xdaniel]

Getting back to the "random junk" this thread is supposed to contain, here's some DS junk for you...

 

 

The old trial mode demo for "Virus Breaker", a DS game I've been working on a few years back. Think I had already posted this on ZSO/ZC back in the day; felt reminded of it when game programming came up in a conversation I had earlier this week, plus when I read about those kids down in Randomness, imagining a 3DS game of their own. I still have the source for it somewhere, but it was coded for some really old versions of devkitPro and PAlib, so I have no idea if it still compiles nowadays...

 

Well, the download: http://magicstone.de...ModeDEMO.sc.rar - should work on No$GBA (make sure you boot it through the firmware, not directly) and a real DS (works on my old Slot-2 M3 Perfect SD anyway)

[DeathBasket]

Wow, SayakaGL, SharpOcarina, a DS game, an N64 demo, a NES emulator, a GB emulator... is there anything you can't do?(!)

[xdaniel]

Wow, SayakaGL, SharpOcarina, a DS game, an N64 demo, a NES emulator, a GB emulator... is there anything you can't do?(!)

 

...hm, see those projects through to completion? ^^" SayakaGL and SharpOcarina are on a kind of hiatus, Virus Breaker here is dead, I guess the same for my N64 stuff (tho I did mess around with Katamari Pyramid a bit a few weeks ago), the NES emulator is highly incomplete and probably won't get much better anytime soon, SharpBoy is also on an extended hiatus, I suppose, so... yeah. "Jack of all trades, but master of none", kinda?

[Zeth Ryder]

Question for you jack of all trades, since you've been working with matrices via the wind waker viewer, anyway possible of fixing up Zsaten to render object models correctly? Its been something that's in been in dire need of not only understanding in the Zelda community for rendering models correctly, but also writing custom actors to handle this.

[xdaniel]

It's possible, I guess. I had already experimented with that a bit ages ago which didn't result in much, however I have a few new ideas and such now, after working on Wind Viewer - who's source and such I'll put out soon as well - so I'll try to go back and fix it up.

[Zeth Ryder]

I definitely appreciate it! I'm sure spinout will also be pleased to see work on matrix support.

[xdaniel]

http://z64.spinout18...msg2328#msg2328 <- my exploits in PC Engine / TurboGrafx-16 emulation...

 

 

---

EDIT:

 

 

Alien Crush: Working; unplayable because of missing sprite emulation

PC Genjin: Appears to hang when going in-game

R-Type: Strange glitches, credits keep counting up, doesn't go in-game, demo mode shows glitched graphics

Space Harrier: Title screen glitched, but appears to be working

Super Star Soldier: Also heavily glitched; at least goes in-game

Vigilante: Same as Alien Crush

 

---

EDIT 2:

 

http://i.imgur.com/N7mKr.pnghttp://i.imgur.com/Yhws6.pnghttp://i.imgur.com/TiogM.pnghttp://i.imgur.com/2CWC3.pnghttp://i.imgur.com/MWYgu.png

 

Besides the still missing sprite support...

 

Parodius: Appears to work; some graphical glitches

PC Genjin: Appears to work as well

Space Harrier: Appears to works; ground now appears in-game, title screen still broken

Super Star Soldier: Appears to work, no more glitches

Edited November 17, 2011 by xdaniel

[Twili]

Maybe this could be adapted to ZSaten? From UltraHLE's source:

 

case 0xda: // LOADMTX

{

int pos,load,push,proj,a;

a=cmd[0]&15;

proj= (a&4);

load= (a&2);

push=!(a&1);

pos=address(cmd[1]);

c_dmamtx(pos,proj,load,push);

}

break;

 

case 0xd8: // POPMTX

g_popmtx(cmd[1]);

break;

 

void c_dmamtx(dword a,int proj,int load,int push)

{

dword addr=address(a);

logd(" {Matrix} at %08X ",addr);

g_loadmtx(addr,proj,load,push);

gst.cnt_mtx++;

}

 

void g_loadmtx(dword pos,int proj,int load,int push)

{

ushort sh[32];

float m[16],m2[16];

int mi[16];

int i,x;

 

proj=(proj!=0);

if(load) logd(" Load:"); else logd(" Mul:");

if(proj) logd("Prj "); else logd("Mod ");

if(push) logd("Push ");

 

gst.newmatrices=1;

gst.lightnumchanged=1;

 

for(i=0;i<32;i+=2)

{

x=mem_read32p(pos+i*2);

sh[i+0]=x>>16;

sh[i+1]=x;

}

 

for(i=0;i<16;i++)

{

mi=((int)sh<<16) | (int)sh[i+16];

m=(float)(mi)*(1.0/65536.0);

}

 

/*

if(gst.mtxstackp[proj]>1)

{

int x,y;

print("4x %08X\n",pos);

for(y=0;y<3;y++) for(x=0;x<3;x++)

{

m[x+y*4]*=4.0;

}

}

*/

 

if(st.dumpgfx)

{

if(load) logd("\nLoad matrix(%i):",proj);

else logd("\nMul matrix(%i):",proj);

if(push) logd(" (push)");

DumpMatrix(m);

}

/*

if(proj)

{

print("-proj-%08X-\n",pos);

PrintMatrix(m);

}

*/

 

if(push)

{

gst.mtxstackp[proj]++;

if(gst.mtxstackp[proj]>15)

{

gst.mtxstackp[proj]--;

error("dlist: matrix stack overflow");

}

memcpy(gst.mtx[proj]+gst.mtxstackp[proj],

gst.mtx[proj]+gst.mtxstackp[proj]-1,16*sizeof(float));

}

 

if(load)

{

memcpy(gst.mtx[proj]+gst.mtxstackp[proj],m,16*sizeof(float));

}

else

{

memcpy(m2,gst.mtx[proj][gst.mtxstackp[proj]],16*sizeof(float));

MultMatrix(gst.mtx[proj][gst.mtxstackp[proj]],m,m2);

}

}

 

void g_popmtx(int num)

{

int proj=0;

if(st.dumpgfx) logd("(stackp=%i) ",gst.mtxstackp[0]);

gst.newmatrices=1;

gst.mtxstackp[proj]--;

if(gst.mtxstackp[proj]<0)

{

gst.mtxstackp[proj]=0;

error("dlist: matrix stack underflow");

}

}

[xdaniel]

If I remember and conclude this correctly, there's two problems with proper matrix support for ZSaten:

 

1) Converting the current bone's OpenGL-side matrix to the N64's format (not difficult) and storing it in the right RAM segment at the right address (more difficult)

2) Manually applying that matrix when requested to each vertex, as you cannot use glTranslate and Co. while OpenGL is rendering a primitive, thus inside glBegin/glEnd (more difficult)

 

It's definitely doable, tho I didn't manage to do it so far. At least part of the functionality from the UHLE source snippet you posted is already in badRDP, but if it worked right last time I worked on the code is a different question altogether... Really need to get back to this at some point...

[spinout]

Oh, xdaniel.

 

I don't know if you're aware of this but I forked badrdp in hopes of making it reentrant and compatible with my other libraries - libobj and libmem32. I'm doing this so I can eventually make z64anim work with libmem32 - the advantage of libmem32 being that it keeps track of pointers when adding and removing bytes.

 

Weather or not you are interested in this fork, I don't know, but it is neat in the sense that it is (supposed) to be reentrant - which gives some advantages, I guess, if you are rendering multiple ucodes at once or something.

[xdaniel]

Cross-posting from z64...

 

---

Random project is random, is done in C# (like 99% of my projects these days), and will probably soon be abandoned for half a year or more (like 99% of my projects these days!)...

 

 

Saving doesn't exist yet, map properties dialog isn't done, no dialog for event editing yet, bunch of stuff to look into that can technically be edited, but I have never messed around with before (map connections, warp-to points), etc., etc.

[Malqua]

Only Pokémon or does it work with other tile-based games?

 

Sent from the Netherworld.

[xdaniel]

That one is Pokemon Generation 1 specific - Red, Green, Blue and Yellow, all regions. The interface code (block selection and placement, event editing, etc) isn't a complete mess for a change, so that's probably reusable for some other games as long as a game handler class is written for it, tho.

 

EDIT: As a follow-up to my shouts from last night:

 

 

EDIT: And another follow-up...

 

Edited February 21, 2012 by xdaniel

[xdaniel]

 

This is roughly where I am now in Pocket Monsters Silver on my Game Boy, hanging around Tanba City, leveling up my Yadon to take on the Fighting-types in the town's Gym. And I know the screenshot's from a Crystal ROM, it's just what I had loaded when I took the shot. Wish I had a Japanese copy of Crystal, preferably complete in box as opposed to my loose Silver...

 

 

...and this is the furthest I could go on my German copy of Pokemon Silver. Before its battery died sometime last year. Taking my 10 years old saved game with it.

[xdaniel]

 

Now capable of saving maps and events (not yet map properties, and I don't even want to get into pointers and stuff...)

 

EDIT:

 

 

...and (naturally?) that's possible for all supported versions:

 

Edited February 28, 2012 by xdaniel

[xdaniel]

It's the big post of status updates! Woohoo!! <(^.^)>

 

...right, yeah, uh. Anyway, this is where I try - both for you guys waiting for a particular project or whatever of mine (looking at you, Zeth and Naxy) and for myself - to piece together what projects I currently have running in whatever capacity, where they stand, and what's gonna happen to them, if anything, in the near future. But, as always, and as annoying as it may be, "no promises, tho"!

 

Going alphabetically by my project folder names...

• BinFind - a binary wildcard searcher, enter a search pattern like "-1.0f32 0x4? 0xA??D? >=0x400000 0xC? 8.5f32 -13.37f64 >=0x3" and get all possible results in that file listed. Last worked on it over a year ago, although it was pretty stable and complete if I recall. Worth picking up again, but no idea when.
• BMDViewer - generic BMD/BDL model viewer, original testbed of the model parsing and rendering class now used in Wind Viewer. Largely superseded by WV, thus pretty much dead by itself.
• G1Map - Pokemon Generation 1 map editor, more or less abandoned for the following project.
• G2Map - Pokemon Generation 2 map editor, came to be from G1Map and advanced much beyond that program's capabilities regarding the G1 games. Works very well, still missing features, will keep working on it.
• GBEmu - SharpBoy, my Game Boy emulator. Last seen being worked on in December, if the date on my last debug EXE is to be believed, was working on serial link emulation if I recall correctly. It's overall a stable emulator, some features need work, the debugger is screaming for rewrites and fixes, so this one's still on the cards, too.
• MapDev - everyone's favorite, SharpOcarina. Honestly, it's a mess, and should be superseded by the following project, but...
• MapDev2 - the "Incubator" rewrite of SharpOcarina. Which still doesn't really do anything, besides being a .obj viewer. This'll be a long, long time in the making until it's ready to replace the original SO, so that one's gonna get fixes and such in the meantime. You really shouldn't hold your breath for the rewrite much, otherwise you'll most likely die.
• MegamanGB - Wily's Toolbox, my Mega Man: Dr. Wily's Revenge editor. Is planned to receive a rewrite as well, which has however sort of evolved into G1Map and G2Map... Not sure what I'll do with it.
• MegamanGB2 - said Wily's Toolbox rewrite, if the folder name didn't already make it obvious. Can barely display level tilesets, let along blocks, levels, enemies, etc., etc. Not sure what to do with this, either.
• N64TexTool - pretty much the reason I'm typing this whole thing up right now, the texture exporter/importer that Zeth and Naxy keep bugging me about. Well, "keep bugging" might be a bit too much, but they are asking for it. From what I have in mind about it right now, this badly needs a rewrite of the core texture loader/converter before I can even get to writing code for importing them. This is also certainly on the cards, but really, I have no idea when I will get to it.
• NESEmulator - the thing that can barely run some NROM games, excluding Super Mario Bros. which was (again) broken last time I bothered with this. Pretty much dead, I guess.
• PCE - my Experimental PC Engine emulator, ExPCE. Overall stable, just like SharpBoy, has some of the same features, like Wiimote support, etc. Does need fixes and rewriting - the awful sound and broken/half-working debugger functions come to mind. Plus, it has slowdown issues and there's still games that don't run correctly. Not dead, but right now not really active, either. On hold, basically.
• RARCPack - GCN RARC archive browser and planned packer. Browsing and extracting files from existing files works perfectly, the code for its actual purpose of importing, replacing, etc., etc. hasn't even been started yet. Maybe will get a pure "browser and extractor" release at some point.
• SayakaGL - has an awful lot of badly written code, just like SO, so I'd really want to rewrite this as well. But not now, if at all. There's way too much on my plate right now - which this list should make rather clear - so I'm not sure about either it or a rewrite.
• SF64Toolkit2 - a rewrite of the original Star Fox 64 Toolkit in C# currently titled "Izuna"; started just yesterday out of boredom, I guess. Is capable of reading and extracting SF64's file system, will become capable of creating a decompressed, MIO0-free ROM soon-ish. Will try to fix the problems the original toolkit had, also gives me an excuse to look into SF64 hacking again (level data, models, etc). Again, just started it yesterday, so - if it'll even happen - it'll probably be long until anything comes out of this.
• SharpBones - Super Mario 64 level viewer, originally thought as a testbed for a more universal variant of Sayaka's Ucode interpreter and renderer. Have actually messed around with it a few days ago, getting textures to show up correctly as opposed to just vertex-colored polygons, but is having Fast3D-related rendering bugs (GeometryMode, how I bloody hate you). The SM64-specific stuff hasn't been worked on much at all, let alone the GUI. Interesting project and maybe worthwhile, but I'm not sure about it. Has a big "maybe" in front of it.
• WWActorEdit - Wind Viewer, the WW and TP map editor. Or well, "actor mover" if you want. Renderer needs at least some improvements (especially for TP support) and I could see about adding support for more chunks. Certainly on the cards.
• WWText - Wind Waker text viewer. Not much I can still do with it, actually, so I guess I'll have another look at it soon, then release a final build with source code or so.
• ZFM - the RARCPack of OoT/MM, I guess. A file system browser and extractor for OoT/MM, originally planned to support rebuilding the ROM. Been almost a year since I worked on it last, probably safe to say it's dead.

Whew. So that's it for what's noteworthy in my VS projects folder... there's other crap in there that never got off the ground, so I didn't include those. Hope this clarifies some things.

[Zeth Ryder]

I know you have a lot of projects and I -really- don't mean to get pushy or annoying about it. I do apologize on that its just it really is something quite vital to a lot of projects and especially the URA Project. Without it, its going to be a pain in the arse to change the title screen, menu, icons, etc that need updating for the project, I literally have nothing that works or within in my grasp to even come close. I do thank you for even taking a look at it to begin with and hope to see a finished version sometime in the near future.

[xdaniel]

There's another pair of extractor/inserter tools I've seen over at Jul, but haven't tried out myself: http://jul.rustedlogic.net/thread.php?id=13199 - be aware that it apparently only supports RGBA16 and... "GA16"? Whatever that's supposed to be. Must be some terminology I'm not familiar with...?

 

As for my own stuff, I'm guessing "Izuna", that is the C# SF64 Toolkit, is my current "obsession" so to speak:

 

 

CRC recalculation has been ported over and implemented, so now it can create expanded ROMs that actually boot. Plus some GUI fixes/improvements here and there (working progress bar, auto-closes form and reloads expanded ROM after 3 seconds when done), compared to the screenshot I shouted last night.

[xdaniel]

 

This'll be an interesting challenge... plus, I'd get to finally redo that typo- and grammar-fail-ridden German translation of mine.

[Xylaphone]

So is your gameboy program moving towards a pokemon editor also?

[xdaniel]

So is your gameboy program moving towards a pokemon editor also?

 

As in, can you use G2Map to change the stats of Pokemon like ex. the base stats? Not yet. I didn't really think about that, actually, although I'm also not sure if that's in the scope of a map editor. Maybe I'll make a separate Pokemon editor for that, I dunno.

[xdaniel]

Yeah, so, tiny bit more info at "Jul -> ROM Hacking -> General screenshots thread". And I'm actively wondering if I should still go to bed, seeing how it's already 6 AM anyway... I'll just end up sleeping through until 4 PM if I do.

 

http://i.imgur.com/qw0Tb.png

 

EDIT: http://imgur.com/a/VN7LU#0 - and I ended up staying awake until noon, then I went to bed and slept until ~4 PM, and now I'm about to go to bed for the night at just past 1 AM.

 

Note that all this has been done from almost zero. All I had documentation-wise was a doc on the PSX GPU, from which I could only gather some concepts (the framebuffer, texture pages and coordinates), nothing else.

Edited July 8, 2012 by xdaniel

[Zeth Ryder]

Yeah, so, tiny bit more info at "Jul -> ROM Hacking -> General screenshots thread". And I'm actively wondering if I should still go to bed, seeing how it's already 6 AM anyway... I'll just end up sleeping through until 4 PM if I do.

 

http://i.imgur.com/qw0Tb.png

 

EDIT: http://imgur.com/a/VN7LU#0 - and I ended up staying awake until noon, then I went to bed and slept until ~4 PM, and now I'm about to go to bed for the night at just past 1 AM.

 

Note that all this has been done from almost zero. All I had documentation-wise was a doc on the PSX GPU, from which I could only gather some concepts (the framebuffer, texture pages and coordinates), nothing else.

 

I'm guessing this could be adapted to work on the N64 version of this as well?