Zeldix Magic Dev Area

by **Euclid** Sun 18 Jun 2017 - 7:27

I'm too busy these days with life otherwise I can give you a hand with the code or data.

If there's something specific you want me to get (especially with regards to stuff HM already does in terms of pointers etc) post it in the admin forums and i'll look at it - I kinda don't pay attention to the other forums.

Looking at the other thread: For overworlds zelda 3 it's coded very similarly to BS Zelda AST dungeons, you can probably have a look at my code in that editor... or I can explain it in more detail if you need specifics

by Mr.x Sun 18 Jun 2017 - 22:48

Euclid wrote:I'm too busy these days with life otherwise I can give you a hand with the code or data.

If there's something specific you want me to get (especially with regards to stuff HM already does in terms of pointers etc) post it in the admin forums and i'll look at it - I kinda don't pay attention to the other forums.

Looking at the other thread: For overworlds zelda 3 it's coded very similarly to BS Zelda AST dungeons, you can probably have a look at my code in that editor... or I can explain it in more detail if you need specifics

Thank you for the response. For right now, I need to know how the game loads graphic data into the VRAM. As seen from Hyrule Magic, the game interleaves the sprite and BG data. I glanced at your pascal code and readme for how the editor handles graphic data loading, but couldn't find it. Could you point me to the file and line number? To elaborate, we're focusing on this window:

by **Euclid** Mon 19 Jun 2017 - 8:15

I actually have a .net 1.1 version of the AST editor - I ditched it because it was too slow (pixel graphics libraries back then suck), but it actually loads data properly

Here's the code for the decompression routine - though you probably have something similar already

Code:: public static Queue decompress (System.IO.FileStream gfx) { /* decompression routine * credit: FuSoYa for zelda 3 decompression doc. * read next byte */ Queue buffer = new Queue(gfxMaxBytes); while (true) { byte codeByte = Convert.ToByte(gfx.ReadByte()); int count = 0; if (codeByte == 0xFF) break; if (buffer.Count > gfxMaxBytes) { Console.WriteLine("Warning, normal gfx size exceeded, stop."); break; } /* * * * if 111x xxxx * newcode = code << 3 & 0xE0 (middle 2 bits for new code) * count2 = read next byte * count = code & 0x03 << 8 || count2 (leftover 2 bits) * else * count = 000x xxxx * count++; */ if ((codeByte & 0xE0) == 0xE0) { count = (codeByte & 3) * 256 + gfx.ReadByte(); codeByte = Convert.ToByte(codeByte << 3 & 0xE0); } else { count = codeByte & 0x1F; } count++; /* case 000x xxxx - $e7ef: * While (count != 0) * read next byte * store buffer * count-- * back to start */ if ((codeByte & 0xE0) == 0) { while (count > 0) { byte tempByte = Convert.ToByte(gfx.ReadByte()); buffer.Enqueue(tempByte); count--; } } /* case 100x xxxx - $e825: * low = read next byte * high = read next byte * offset = high << 8 | low * while (count != 0) * read $00? + offset <----- RECHECK. * store buffer * count-- * back to start */ else if((codeByte & 0xE0) == 0x80) { int offset = gfx.ReadByte() | gfx.ReadByte() << 8; object[] objs = buffer.ToArray(); while (count > 0) { buffer.Enqueue(objs[offset]); count--; offset++; } } /* case 001x xxxx - $e7fe: * byte = read next byte * while (count != 0) * store buffer * count-- * back to start */ else if ((codeByte & 0xE0) == 0x20) { byte temp = Convert.ToByte(gfx.ReadByte()); while (count > 0) { buffer.Enqueue(temp); count--; } } /* case 010x xxxx - $e80b: * byte1 = read next byte * byte2 = read next byte * while (count != 0) * store byte1 * count--; * if count == 0 break. * store byte2 * count--; * back to start */ else if ((codeByte & 0xE0) == 0x40) { byte temp1 = Convert.ToByte(gfx.ReadByte()); byte temp2 = Convert.ToByte(gfx.ReadByte()); while(count >0) { buffer.Enqueue(temp1); count--; if (count <= 0) break; buffer.Enqueue(temp2); count--; } } /* case 011x xxxx - $e7e1: (ALSO ELSE CASE) * byte = read next byte; * while (count != 0) * store byte * byte++ * count-- * back to start * */ else { byte temp = Convert.ToByte(gfx.ReadByte()); while(count > 0) { buffer.Enqueue(temp); temp++; count--; } } } return buffer; }

Once you have completely decompressed the graphics, divide them up in 64 - each division here is basically a set. In programming speak I'm refering to something like below

graphics[N][64] = Each 8x8Tile
graphics[N] = A set (i.e. 64 of the 8x8 Tiles)

The number N there represents the graphics set number. Notice there are 8 numbers on the left? It means to use
Graphics[0]
Graphics[1]
Graphics[16]
Graphics[6]
Graphics[14]
Graphics[31]
Graphics[24]
Graphics[15]
Those graphics are what's showing on the right (you can cross verify what I said by decompressing lttp graphics via zcompress and check the Graphics locations corresponding to the above)

Sprite blockset works in a similar manner to the sprite data (it's still in the graphics, I think it's hardcode offseted by a number, eg/ Graphics[200] = SpriteBlockset[0])

So my c# loading code for the dungeon rom is as follows - note the following is for AST, the actual locations in lttp will be very different - but should already be documented somewhere

Code:: public void readGFX(FileStream s) { byte[] highTemp = new Byte[SharedConstants.GFXBlockNumber]; byte[] midTemp = new Byte[SharedConstants.GFXBlockNumber]; byte[] lowTemp = new Byte[SharedConstants.GFXBlockNumber]; long[] pcaddrs = new long[SharedConstants.GFXBlockNumber]; s.Seek(SharedConstants.gfxPointerHigh + SharedConstants.header,SeekOrigin.Begin); for (int i = 0; i < SharedConstants.GFXBlockNumber; i++) highTemp[i] = Convert.ToByte(s.ReadByte()); s.Seek(SharedConstants.gfxPointerMid + SharedConstants.header,SeekOrigin.Begin); for (int i = 0; i < SharedConstants.GFXBlockNumber; i++) midTemp[i] = Convert.ToByte(s.ReadByte()); s.Seek(SharedConstants.gfxPointerLow + SharedConstants.header,SeekOrigin.Begin); for (int i = 0; i < SharedConstants.GFXBlockNumber; i++) lowTemp[i] = Convert.ToByte(s.ReadByte()); for (int i = 0; i < SharedConstants.GFXBlockNumber; i++) pcaddrs[i] = SharedConstants.SNESToPC(lowTemp[i],midTemp[i],highTemp[i]); for (int k = 0; k < SharedConstants.GFXBlockNumber; k++) { s.Seek(pcaddrs[k] +SharedConstants.header,SeekOrigin.Begin); Queue gfxList = SharedConstants.decompress(s); //Console.WriteLine("Decompressing "+ k.ToString() + "... count:" + gfxList.Count.ToString()); for (int j = 0; j < SharedConstants.tileLimitPerGFXBlock; j++) { byte[] gfx = new byte[0x18]; for (int i = 0; i < 0x18; i++) gfx[i] = Convert.ToByte(gfxList.Dequeue()); SharedConstants._8x8Data[k][j] = new tile8x8(gfx); } } readAnimationGFX(s); }

I hope this is the sort of thing you're asking for, feel free to yell at me if i'm just giving you stuff you already know.

EDIT: the same thing is in my pascal code - basically lttp is all about gfx sets, if you get your head around that then it becomes easier.

Look for
procedure TBsz3rom.readGFX;
procedure TBsz3rom.readAnimationGFX;

All get called by
procedure Tbsz3rom.readData;
when the file is loaded.

by Mr.x Mon 19 Jun 2017 - 9:14

MathOnNapkins wrote:I do not distribute the Hyrule Magic source code just as a matter of principle because I was asked not to. That said, if you could actually see the source I don't think you'd consider it to be that useful. It's very cryptic, to the point that I think what was given to me was run through an obfuscation script of some sort.

Just sent him the source code I have. Currently waiting for his response. Very Happy

Also thanks Euclid, will dive into that when I can.

by **Euclid** Mon 19 Jun 2017 - 9:20

Alright all done (I'm feeling stupid that I didn't click on the blue not underlined moderate link on the bottom)

People here have asked for the source in the past, I would not recommend it as from the screenshots I've seen on it, it's pretty much completely undocumented.

There's rom offset documents floating around for zelda 3, relying on HM's code will just mean you'll make the same mistakes HM did on designing the tool so I wouldn't recommend it.

Later this week what i'll do is take a snap of your code and see where you're up to...

by Mr.x Mon 19 Jun 2017 - 13:47

MathOnNapkins wrote:
Trovsky wrote:In case you're curious, the Hyrule Magic exe contains uncompiled source code for whatever reason. That's where I got it from.

That is really ... odd, but not unheard of. There are numerous commercial video games that have chunks of source code embedded in them (see tcrf.net). It also explains why 0.962, which was released by sephiroth3, is 917 KB, and the version (0.965) I last compiled is 376 KB. It because it doesn't have that source embedded in it. The source code you linked to comprises about half of the editor's source, assuming it compiles down to the same machine code as the binary itself.

by Mr.x Mon 19 Jun 2017 - 14:17

I read your post. I can already decompress graphics. I can browse all the graphic sets with the ZCompress option in Zeldix Magic. Here's how I get the addresses for each GFX set. And here's how I use that address to decompress.

by **Euclid** Tue 20 Jun 2017 - 8:55

Had a quick look at some of your code on git... I don't think I can contribute without completely slashing away your code... sorry!

Some advise: if you try to replicate each screen in HM as an editor without actually understanding how it loads and keeps its data structures in memory - you're most likely not going to get anywhere for a long time.

You're not being clear what you're asking for then if I'm not pointing you to the correct data - the graphics on the right are based off graphic sets in the decompressed zcompress - the blockset numbers on the left refer to the graphic sets in zcompress

by Mr.x Tue 20 Jun 2017 - 18:45

Euclid wrote:You're not being clear what you're asking

When I made that post, I don't think I slept at all that night. My post assumed you read my comment on my other thread considering you stated you viewed it.

Euclid wrote:Had a quick look at some of your code on git... I don't think I can contribute without completely slashing away your code... sorry!

If you have anything in particular wrong with my code, please point them out.

The number N there represents the graphics set number. Notice there are 8 numbers on the left? It means to use
Graphics[0]
Graphics[1]
Graphics[16]
Graphics[6]
Graphics[14]
Graphics[31]
Graphics[24]
Graphics[15]
Those graphics are what's showing on the right (you can cross verify what I said by decompressing lttp graphics via zcompress and check the Graphics locations corresponding to the above)

That's the issue, these are not the graphic sets shown on screen in Hyrule Magic. With vanilla ALttP, changing the decimal number 14 to 0 does not show a change in the graphics window. In other words, it's not a simple sequential display. If you change the second decimal number to 0 in the room blockset, now it displays the 14th blockset.

the graphics on the right are based off graphic sets in the decompressed zcompress - the blockset numbers on the left refer to the graphic sets in zcompress

This might be an example of a vanilla AlttP engine difference from BS Zelda, or a case of Hyrule Magic bugging out. In any case, the display is not a sequential display. Some graphic sets will not display in Hyrule Magic despite having an entry. In other words, the BG and Sprite graphics are interleaved with each in the editor and can overwrite eachother.

Euclid wrote:Some advise: if you try to replicate each screen in HM as an editor without actually understanding how it loads and keeps its data structures in memory - you're most likely not going to get anywhere for a long time.

HM doesn't use much data structuring as revealed by it's source code. This is a major reason why editing monologues glitches the Ganon fight. Considering MoN will will probably release the source code for Hyrule Magic soon, I might be better off looking at that.

by **SunGodPortal** Tue 20 Jun 2017 - 21:29

That's the issue, these are not the graphic sets shown on screen in Hyrule Magic. With vanilla ALttP, changing the decimal number 14 to 0 does not show a change in the graphics window.

It might just not be changing the ones that are currently on display. You may have to scroll down depending on which values you are altering. Also remember to have the palette set on 5 or 6, otherwise you may not be able to see some or all of it.

by Mr.x Tue 20 Jun 2017 - 22:45

SunGodPortal wrote:
That's the issue, these are not the graphic sets shown on screen in Hyrule Magic. With vanilla ALttP, changing the decimal number 14 to 0 does not show a change in the graphics window.

It might just not be changing the ones that are currently on display. You may have to scroll down depending on which values you are altering. Also remember to have the palette set on 5 or 6, otherwise you may not be able to see some or all of it.

I appreciate the reply. This is not the issue here unfortunately. This may be a glitch in HM considering there's a big blank space that's present that's black regardless of the palette. This may be a case of Hyrule Magic writing the graphic entries in the wrong location in the view, it could be a really weird ALttP engine "feature", or it could be a glitch in the OS or hardware.

Euclid wrote:Had a quick look at some of your code on git... I don't think I can contribute without completely slashing away your code... sorry!

The squeaky wheel gets the grease. I realize your post had hints of frustration mostly because you're a busy person and that my question was vague. Sorry.

by **Euclid** Wed 21 Jun 2017 - 5:04

that quote is coming from 10 years of professional software dev experience. There's not too much structure in the code at the moment and i'm sensing project/dll overload at some stage and hardcoded values everywhere.

I'll check that editor in hm later tonight - pretty sure its a blockset gfx load, that or theres a set of intermediate pointers in the rom which werent there in bs zelda

by **Euclid** Wed 21 Jun 2017 - 8:46

heh that editor I've never used myself, for your reference it has nothing to do with how it's loaded in SNES GPU.

that picture should explain wtf is going on with that editor - the data is in the rom somewhere which I never bothered to dig up.

As for ASTDE.... if you check out settings.pas

Code:: procedure global.init; begin currentRoom := 97; real16x16Length := 0; roomBlockset := $F; entranceBlockset := $F; blocksetMap[0] := 0; blocksetMap[1] := 1 ; blocksetMap[2] := $10; blocksetMap[3] := $7; blocksetMap[4] := $E; blocksetMap[5] := $23; blocksetMap[6] := $1C; blocksetMap[7] := $F;

Notice how similar the blocksetMap numbers are to your screenshot Razz

Attachments

: WTF Graphics Schemes.png You don't have permission to download attachments.(93 Kb) Downloaded 10 times

by Mr.x Wed 21 Jun 2017 - 12:13

Euclid wrote:that quote is coming from 10 years of professional software dev experience. There's not too much structure in the code at the moment and i'm sensing project/dll overload at some stage and hardcoded values everywhere.

I'll check that editor in hm later tonight - pretty sure its a blockset gfx load, that or theres a set of intermediate pointers in the rom which werent there in bs zelda

Well I did change the BPP decompression code because it did look like crap. So check it out. I though having different solutions for each part of the project was a better idea. Should I avoid doing that. As for embedded values, I tried not to and have private constant variables for every class. If you want, can you audit the code? Also that picture is a huge help.

by Mr.x Wed 21 Jun 2017 - 14:08

Euclid wrote:that quote is coming from 10 years of professional software dev experience. There's not too much structure in the code at the moment and i'm sensing project/dll overload at some stage and hardcoded values everywhere.

Pushed a new commit that removes the project/dll overload. You'll have to be more specific where the bad structure and hardcoded values are. If you want these coding issues fixed, then sign up on GitHub and report issues, or tell me where it is, or else these issues won't be fixed. I am aware the hex and enemy editor code suck, but that code isn't mine. I know the the credit code sucks, I just just never bothered fixing it up. If you want to see better and structured code, see the overworld and monologue code. If you don't think this code is structured, I don't know what to tell you.

Zeldix Magic Dev Area

Zeldix Magic Dev Area

Re: Zeldix Magic Dev Area

Re: Zeldix Magic Dev Area

Zeldix Magic Admin Dev Area

Re: Zeldix Magic Dev Area

Re: Zeldix Magic Dev Area

Re: Zeldix Magic Dev Area

Re: Zeldix Magic Dev Area

Re: Zeldix Magic Dev Area

Re: Zeldix Magic Dev Area

Re: Zeldix Magic Dev Area

Re: Zeldix Magic Dev Area

Re: Zeldix Magic Dev Area

Re: Zeldix Magic Dev Area

Re: Zeldix Magic Dev Area