<- 1  -   of 75 ->
^^
vv
List results:
Search options:
Use \ before commas in usernames
jackoalan
2016-06-10 10:19:52 pm
With any sort of tile-based texture storage, you must bail the mip-map generation at or larger than the tile resolution on the smallest axis. As long as the mip count in the header is indeed correct, the GPU will only go that small when set as the max texture LOD.

My guess is Retro shared the 8x8 code with the smaller texel-format tiles as well.

Rather negligible anyway, it'll fall back to blurry bilinear interpolation on an already tiny 8x8 mapping in the game viewport. Actually does a good job of fuzzing far-away things nicely for 480-line presentation
Antidote
2016-06-11 02:57:19 pm
Just found something interesting about Space Pirates: The first character node is a hard coded fail case, if a Space Pirate has it's character node set to 0 the engine would issue a warning, then force the node to 2, which is virtually identical to 0 with, I believe, a more complete animation set.
Aruki
Aruki
Edit history:
Aruki: 2016-06-19 12:46:09 pm
2016-06-19 12:43:20 pm
Anyone feel like taking a crack at any of these formats?

* CAUD (MP3/DKCR)
* CHAR (DKCR)
* FRME (all)
* SAND (MP3)
* I'm assuming all the particle formats are mostly the same, but if that's not the case, insert any of them that are unknown here

These are I think all the formats that AFAIK are either unknown or don't have comprehensive docs, and have dependencies. I want to work on rebuilding paks from scratch pretty soon so I want to be able to get a full list of dependencies for every resource type, so I gotta know how to at least parse all of these.

SAND I tried looking at a little bit ago and I made some progress, but it seems to be similar to ANCS/CHAR with enums that indicate different struct types, so I couldn't work out how to fully parse it.
Antidote
2016-06-25 08:34:02 pm
I've cracked FRME, but I haven't cracked SAND yet.
Antidote
Antidote
Edit history:
Antidote: 2016-06-26 01:13:50 am
2016-06-26 01:10:47 am
Jack has been busting his butt for the past month and a half working on our reimplementation of MusyX, the SFX engine and midi sequencer by Factor5 that retro used for all of their SFX before switching to FMOD, and we now have virtually perfect representation of both SON (midi) and the sound macros used to build sound effects, as an example here is the sound macro for laying the powerbomb in all it's glory:

https://dl.dropboxusercontent.com/u/21757902/laybomb.wav

Check it out here:
https://github.com/AxioDL/amuse/releases

All you need to do is pass it an AudioGrp and select the desired AGSC and have fun!
If you run into any errors please post a detailed issue on Amuse's issue tracker here: https://github.com/AxioDL/amuse/issues/
Please make sure your issue is unique, if not post in the issue's comments with your details.
Odylg
2016-07-05 04:27:57 am
I run this here hotel of an evening
Is there any documentation on f1ed8fd7.CTWK (Player Controls) by chance? I didn't see any specifics on the wiki CTWK page, but I didn't see it listed as needing research either.
Aruki
Aruki
Edit history:
Aruki: 2016-07-05 04:39:53 am
Aruki: 2016-07-05 04:30:46 am
2016-07-05 04:30:37 am
yeah it seems like Miles mostly figured that one out but it's not on the wiki as of right now.

Code:
<?xml version="1.0" ?>
<TweakPlayerControls>
	<enum name="Forward" template="Enums/ControllerButton.xml" />
	<enum name="Backward" template="Enums/ControllerButton.xml" />
	<enum name="Turn Left" template="Enums/ControllerButton.xml" />
	<enum name="Turn Right" template="Enums/ControllerButton.xml" />
	<enum name="Strafe Left" template="Enums/ControllerButton.xml" />
	<enum name="Strafe Right" template="Enums/ControllerButton.xml" />
	<enum name="Look Left" template="Enums/ControllerButton.xml" />
	<enum name="Look Right" template="Enums/ControllerButton.xml" />
	<enum name="Look Up" template="Enums/ControllerButton.xml" />
	<enum name="Look Down" template="Enums/ControllerButton.xml" />
	<enum name="Jump/Boost" template="Enums/ControllerButton.xml" />
	<enum name="Fire/Bomb" template="Enums/ControllerButton.xml" />
	<enum name="Missile/PowerBomb" template="Enums/ControllerButton.xml" />
	<enum name="Morph" template="Enums/ControllerButton.xml" />
	<enum name="Aim Up" template="Enums/ControllerButton.xml" />
	<enum name="Aim Down" template="Enums/ControllerButton.xml" />
	<enum name="Cycle Beam Up" template="Enums/ControllerButton.xml" />
	<enum name="Cycle Beam Down" template="Enums/ControllerButton.xml" />
	<enum name="Cycle Item" template="Enums/ControllerButton.xml" />
	<enum name="Power Beam" template="Enums/ControllerButton.xml" />
	<enum name="Ice Beam" template="Enums/ControllerButton.xml" />
	<enum name="Wave Beam" template="Enums/ControllerButton.xml" />
	<enum name="Plasma Beam" template="Enums/ControllerButton.xml" />
	<enum name="Toggle Holster" template="Enums/ControllerButton.xml" />
	<enum name="Orbit Close" template="Enums/ControllerButton.xml" />
	<enum name="Orbit Far" template="Enums/ControllerButton.xml" />
	<enum name="Orbit Object" template="Enums/ControllerButton.xml" />
	<enum name="Orbit Select" template="Enums/ControllerButton.xml" />
	<enum name="Orbit Confirm" template="Enums/ControllerButton.xml" />
	<enum name="Orbit Left" template="Enums/ControllerButton.xml" />
	<enum name="Orbit Right" template="Enums/ControllerButton.xml" />
	<enum name="Orbit Up" template="Enums/ControllerButton.xml" />
	<enum name="Orbit Down" template="Enums/ControllerButton.xml" />
	<enum name="Look Hold1" template="Enums/ControllerButton.xml" />
	<enum name="Look Hold2" template="Enums/ControllerButton.xml" />
	<enum name="Look Zoom In" template="Enums/ControllerButton.xml" />
	<enum name="Look Zoom Out" template="Enums/ControllerButton.xml" />
	<enum name="Aim Hold" template="Enums/ControllerButton.xml" />
	<enum name="Map Circle Up" template="Enums/ControllerButton.xml" />
	<enum name="Map Circle Down" template="Enums/ControllerButton.xml" />
	<enum name="Map Circle Left" template="Enums/ControllerButton.xml" />
	<enum name="Map Circle Right" template="Enums/ControllerButton.xml" />
	<enum name="Map Move Forward" template="Enums/ControllerButton.xml" />
	<enum name="Map Move Back" template="Enums/ControllerButton.xml" />
	<enum name="Map Move Left" template="Enums/ControllerButton.xml" />
	<enum name="Map Move Right" template="Enums/ControllerButton.xml" />
	<enum name="Map Zoom In" template="Enums/ControllerButton.xml" />
	<enum name="Map Zoom Out" template="Enums/ControllerButton.xml" />
	<enum name="SpiderBall" template="Enums/ControllerButton.xml" />
	<enum name="Chase Camera" template="Enums/ControllerButton.xml" />
	<enum name="XRay Visor" template="Enums/ControllerButton.xml" />
	<enum name="Thermo Visor" template="Enums/ControllerButton.xml" />
	<enum name="Enviro Visor" template="Enums/ControllerButton.xml" />
	<enum name="No Visor" template="Enums/ControllerButton.xml" />
	<enum name="Visor Menu" template="Enums/ControllerButton.xml" />
	<enum name="Visor Up" template="Enums/ControllerButton.xml" />
	<enum name="Visor Down" template="Enums/ControllerButton.xml" />
	<enum name="UNKNOWN 1" template="Enums/ControllerButton.xml" />
	<enum name="UNKNOWN 2" template="Enums/ControllerButton.xml" />
	<enum name="Use Shield" template="Enums/ControllerButton.xml" />
	<enum name="Scan Item" template="Enums/ControllerButton.xml" />
	<enum name="UNKNOWN 3" template="Enums/ControllerButton.xml" />
	<enum name="UNKNOWN 4" template="Enums/ControllerButton.xml" />
	<enum name="UNKNOWN 5" template="Enums/ControllerButton.xml" />
	<enum name="UNKNOWN 6" template="Enums/ControllerButton.xml" />
	<enum name="UNKNOWN 7" template="Enums/ControllerButton.xml" />
	<enum name="UNKNOWN 8" template="Enums/ControllerButton.xml" />
</TweakPlayerControls>


Code:
<?xml version="1.0" ?>
<enum name="ControllerButton">
    <enumerator ID="0x00" name="None" />
    <enumerator ID="0x01" name="Left Stick Up" />
    <enumerator ID="0x02" name="Left Stick Down" />
    <enumerator ID="0x03" name="Left Stick Left" />
    <enumerator ID="0x04" name="Left Stick Right" />
    <enumerator ID="0x05" name="Right Stick Up" />
    <enumerator ID="0x06" name="Right Stick Down" />
    <enumerator ID="0x07" name="Right Stick Left" />
    <enumerator ID="0x08" name="Right Stick Right" />
    <enumerator ID="0x09" name="Left Trigger" />
    <enumerator ID="0x0A" name="Right Trigger" />
    <enumerator ID="0x0B" name="D-Pad Up" />
    <enumerator ID="0x0C" name="D-Pad Down" />
    <enumerator ID="0x0D" name="D-Pad Left" />
    <enumerator ID="0x0E" name="D-Pad Right" />
    <enumerator ID="0x0F" name="A Button" />
    <enumerator ID="0x10" name="B Button" />
    <enumerator ID="0x11" name="X Button" />
    <enumerator ID="0x12" name="Y Button" />
    <enumerator ID="0x13" name="Z Button" />
    <enumerator ID="0x14" name="Left Trigger Press" />
    <enumerator ID="0x15" name="Right Trigger Press" />
    <enumerator ID="0x16" name="Start" />
</enum>
Antidote
Antidote
Edit history:
Antidote: 2016-07-05 05:15:15 am
Antidote: 2016-07-05 05:14:10 am
2016-07-05 05:05:47 am
In this case "mostly" = "completely"
Those "Unknowns" Miles got directly from the binary, ControlMapper redirects those to an "UNKNOWN" string.

EDIT:
The way that CTweakPlayerControl works is that it's read in using a loop, the value of "i" being the ECommand value, so the order of the names directly map to an ECommand (except for UNKNOWNS, only the first 3 are handled, the others are a default case). This way you have one level of indirection: The ECommand.
Odylg
Odylg
Edit history:
Odylg: 2016-07-05 08:13:32 am
2016-07-05 07:53:18 am
I run this here hotel of an evening
Awesome. This is making more sense now.

Except which one actually opens the map? i'm not seeing 0x13. Or is Open Map not a player action?

Edit: Come to think of it, that'd probably be in the GUI pak wouldn't it?
Antidote
Antidote
Edit history:
Antidote: 2016-07-05 01:04:27 pm
Antidote: 2016-07-05 01:03:04 pm
Antidote: 2016-07-05 01:02:35 pm
Antidote: 2016-07-05 12:14:33 pm
2016-07-05 12:13:36 pm
No, that's in Tweaks/PlayerControls, are you sure you're looking at the right one? There are two of them, one which is used in normal gameplay (PlayerControls CTWK), and one which is completely different (PlayerControls2), PlayerControls2 is used as a fallback if PlayerControls can't be loaded (which would royally suck if it happened, lol)

EDIT:
Actually, I think you're confusing meanings: the commands are the names (e.g Map Zoom In), the Controls are referred to as "Functions" 0x13 being the Z button. So count up to Map Zoom In, and check the value there.
Odylg
2016-07-06 02:44:00 am
I run this here hotel of an evening
The value of Map Zoom In is 15. The function 0x15 is "R" which is the button that zooms the map in
<enumerator ID="0x15" name="Right Trigger Press" />

I don't doubt that my terminology was/is wrong, but I managed to switch the X and Y buttons so i can't be too far off, can i?
i also managed to switch Strafe Left and Strafe Right to C-Stick Left and C-Stick Right the same way.
Both were achieved using HxD to change F1ED8FD7.CTWK
Should i not be using a hex editor for this?

X & Y:
<enum name="Missile/PowerBomb" template="Enums/ControllerButton.xml" /> offset 33 (default value: 12)
<enumerator ID="0x12" name="Y Button" />

<enum name="Morph" template="Enums/ControllerButton.xml" /> offset 37 (default value: 11)
<enumerator ID="0x11" name="X Button" />

So when i change the value at offset 33 to 11 and the value at offset 37 to 12 i'm able to fire missiles with X and morph with Y


Same for Strafe Left/Right:
<enum name="Strafe Left" template="Enums/ControllerButton.xml" /> offset 13 (default value: 03)
<enumerator ID="0x03" name="Left Stick Left" />
<enumerator ID="0x07" name="Right Stick Left" />

<enum name="Strafe Right" template="Enums/ControllerButton.xml" /> offset 17 (default value: 04)
<enumerator ID="0x04" name="Left Stick Right" />
<enumerator ID="0x08" name="Right Stick Right" />

Changing the value of offset 13 to 07 and the value of offset 17 to 08 makes it so i can strafe with the C-Stick Left/Right instead of Control-Stick Left/Right


The issue i'm running into as far as i can tell is that none of these commands...
"Map Circle Up"    (Function 0x01) offset
"Map Circle Down"  (Function 0x02) offset
"Map Circle Left"  (Function 0x03) offset
"Map Circle Right" (Function 0x04) offset
"Map Move Forward" (Function 0x05) offset
"Map Move Back"    (Function 0x06) offset
"Map Move Left"    (Function 0x07) offset
"Map Move Right"  (Function 0x08) offset
"Map Zoom In"      (Function 0x14) offset
"Map Zoom Out"    (Function 0x15) offset
...use function 0x13. None of those open/close the map, they control how the map is viewed while it's open.


I'm looking for the command that actually opens/closes the map, but i don't know what the "name" of that command is.
From what i've seen it doesn't appear to be in F1ED8FD7.CTWK

i'm clearly missing something. am i totally off base in thinking that the values seen in HxD represent the functions used to trigger the commands? for example is the value at offset 33, which is 12, not indicitive of the function 0x12?

or maybe i'm counting wrong?


Also, the changes i make to the controls only seem to work when Swap Beam Controls is OFF. if i turn that option ON the controls revert to the unchanged ones. turned OFF again and my changes come back. i haven't touched PlayerControls2 beyond just looking at it in HxD
Aruki
Aruki
Edit history:
Aruki: 2016-07-06 03:17:57 am
2016-07-06 03:14:41 am
you're editing the file correctly. I've got no clue which one would refer to the map, since as you said there's nothing in there mapped to the Z button. There's no entry for "pause" either (the only thing mapped to Start is one of the UNKNOWN values near the end) so maybe they've just hardcoded the buttons for those things?

also, it'd be interesting if PlayerControls2 was used for the swapped control schemes. You could try editing it and see if that changes it.
Odylg
Odylg
Edit history:
Odylg: 2016-07-06 10:01:23 am
2016-07-06 03:27:39 am
I run this here hotel of an evening
Apparently it is used for the swapped controls. Neat

Edit: Forgot to mention this earlier. Using the Left Stick for going forward/backward and the Right Stick for Strafe left/right you move faster than you would walking straight. If you've ever played "Perfect Dark" using the 1.2 control scheme or the alternate control scheme on the Xbox version of "Call of Cthulhu: Dark Corners of the Earth" then you've seen the extra speed. I read somewhere that it's a 40% speed gain for PD. CoC: DCOTE seems to have about the same, but Prime doesn't seem quite as fast as the others. It's difficult to control on this game since you still have to hold "L" to strafe. Cool concept though
Baby Sheegoth
2016-07-07 02:16:21 am
Wait what? How do you control the game? This sounds weird as shit.
Aruki
Aruki
Edit history:
Aruki: 2016-07-14 02:30:17 am
2016-07-14 02:24:32 am
Did some research into pak file ordering. I hacked at Dolphin a little bit to show me exactly which resources (and which copies of each resource) are being loaded in what order. Here's the output, showing the game loading Map Facility:

Code:
09:07:488 Reading Metroid1.pak 059d879b.TXTR (Offset: 0x00021300 / DupeNum: 0)
09:07:539 Reading Metroid1.pak 07b9c7b5.TXTR (Offset: 0x013c9960 / DupeNum: 0)
09:07:597 Reading Metroid1.pak 08fd5b8e.TXTR (Offset: 0x00030e40 / DupeNum: 0)
09:07:647 Reading Metroid1.pak 0be13e51.TXTR (Offset: 0x00031d60 / DupeNum: 0)
09:07:648 Reading Metroid1.pak 13313bae.TXTR (Offset: 0x0098a100 / DupeNum: 0)
09:07:698 Reading Metroid1.pak 1620f789.TXTR (Offset: 0x013cebe0 / DupeNum: 0)
09:07:752 Reading Metroid1.pak 1a2a38e5.TXTR (Offset: 0x013cf520 / DupeNum: 0)
09:07:752 Reading Metroid1.pak 1a5651b3.TXTR (Offset: 0x0005e660 / DupeNum: 0)
09:07:813 Reading Metroid1.pak 20143f6c.TXTR (Offset: 0x013cfa00 / DupeNum: 0)
09:07:864 Reading Metroid1.pak 2bcedad4.TXTR (Offset: 0x00073c40 / DupeNum: 0)
09:07:929 Reading Metroid1.pak 3168ade9.TXTR (Offset: 0x013d0680 / DupeNum: 0)
09:08:100 Reading Metroid1.pak 38c12207.TXTR (Offset: 0x013d16c0 / DupeNum: 0)
09:08:150 Reading Metroid1.pak 3bada4f0.TXTR (Offset: 0x013d3260 / DupeNum: 0)
09:08:160 Reading Metroid1.pak 4a7166be.TXTR (Offset: 0x013d4320 / DupeNum: 0)
09:08:164 Reading Metroid1.pak 4b3014ee.TXTR (Offset: 0x000b0680 / DupeNum: 0)
09:08:224 Reading Metroid1.pak 4fa014d7.TXTR (Offset: 0x013d9bc0 / DupeNum: 0)
09:08:279 Reading Metroid1.pak 5497b699.TXTR (Offset: 0x000b73a0 / DupeNum: 0)
09:08:329 Reading Metroid1.pak 54e19269.TXTR (Offset: 0x000b7840 / DupeNum: 0)
09:08:331 Reading Metroid1.pak 569c8708.TXTR (Offset: 0x013dd780 / DupeNum: 0)
09:08:381 Reading Metroid1.pak 57745606.TXTR (Offset: 0x013dda40 / DupeNum: 0)
09:08:393 Reading Metroid1.pak 5b9e82ec.TXTR (Offset: 0x013e2dc0 / DupeNum: 0)
09:08:395 Reading Metroid1.pak 5c598e11.TXTR (Offset: 0x013e3780 / DupeNum: 0)
09:08:396 Reading Metroid1.pak 6359ffa0.TXTR (Offset: 0x000cbd00 / DupeNum: 0)
09:08:446 Reading Metroid1.pak 65268395.TXTR (Offset: 0x000cc6c0 / DupeNum: 0)
09:08:447 Reading Metroid1.pak 7539e8c8.TXTR (Offset: 0x000e55c0 / DupeNum: 0)
09:08:480 Reading Metroid1.pak 7988a38d.TXTR (Offset: 0x013e3900 / DupeNum: 0)
09:08:531 Reading Metroid1.pak 7ef0d570.TXTR (Offset: 0x000fcb40 / DupeNum: 0)
09:08:581 Reading Metroid1.pak 812db51b.TXTR (Offset: 0x013e48e0 / DupeNum: 0)
09:08:643 Reading Metroid1.pak 8ac6c1fe.TXTR (Offset: 0x0010ac80 / DupeNum: 0)
09:08:693 Reading Metroid1.pak 8e25b646.TXTR (Offset: 0x013ea7a0 / DupeNum: 0)
09:08:745 Reading Metroid1.pak 93a5b530.TXTR (Offset: 0x00111840 / DupeNum: 0)
09:08:795 Reading Metroid1.pak 966869eb.TXTR (Offset: 0x00115a20 / DupeNum: 0)
09:08:797 Reading Metroid1.pak 995a0161.TXTR (Offset: 0x013eb060 / DupeNum: 0)
09:08:848 Reading Metroid1.pak 9c2885a3.TXTR (Offset: 0x013ed380 / DupeNum: 0)
09:08:855 Reading Metroid1.pak 9ca646ef.TXTR (Offset: 0x0011ba00 / DupeNum: 0)
09:08:910 Reading Metroid1.pak 9d114e07.TXTR (Offset: 0x013f01a0 / DupeNum: 0)
09:08:965 Reading Metroid1.pak a2763848.TXTR (Offset: 0x00124420 / DupeNum: 0)
09:09:016 Reading Metroid1.pak a3d29eca.TXTR (Offset: 0x00124dc0 / DupeNum: 0)
09:09:016 Reading Metroid1.pak ad7ee888.TXTR (Offset: 0x0012a320 / DupeNum: 0)
09:09:029 Reading Metroid1.pak b057fc3d.TXTR (Offset: 0x0012b180 / DupeNum: 0)
09:09:031 Reading Metroid1.pak bbb11b83.TXTR (Offset: 0x00135240 / DupeNum: 0)
09:09:055 Reading Metroid1.pak bc990aeb.TXTR (Offset: 0x008bb5a0 / DupeNum: 0)
09:09:105 Reading Metroid1.pak bfcdacdb.TXTR (Offset: 0x013f8440 / DupeNum: 0)
09:09:160 Reading Metroid1.pak c2c2dcc6.TXTR (Offset: 0x0013df40 / DupeNum: 0)
09:09:210 Reading Metroid1.pak c75908e3.TXTR (Offset: 0x013f8e20 / DupeNum: 0)
09:09:262 Reading Metroid1.pak cce51410.TXTR (Offset: 0x013fa8a0 / DupeNum: 0)
09:09:265 Reading Metroid1.pak d2a17ca6.TXTR (Offset: 0x001529a0 / DupeNum: 0)
09:09:316 Reading Metroid1.pak de5facec.TXTR (Offset: 0x001600a0 / DupeNum: 0)
09:09:333 Reading Metroid1.pak e5528eed.TXTR (Offset: 0x008c3340 / DupeNum: 0)
09:09:383 Reading Metroid1.pak f2cc59af.TXTR (Offset: 0x00178980 / DupeNum: 0)
09:09:439 Reading Metroid1.pak f707a46e.TXTR (Offset: 0x013ffea0 / DupeNum: 0)
09:09:498 Reading Metroid1.pak fdc2ad77.TXTR (Offset: 0x01407dc0 / DupeNum: 0)
09:09:499 Reading Metroid1.pak 5bf00d2f.PATH (Offset: 0x01470800 / DupeNum: 0)
09:09:549 Reading Metroid1.pak f05cf30e.TXTR (Offset: 0x01409ba0 / DupeNum: 0)
09:09:599 Reading Metroid1.pak abeff41b.CMDL (Offset: 0x01409da0 / DupeNum: 0)
09:09:599 Reading Metroid1.pak 501b7d88.PART (Offset: 0x01409e60 / DupeNum: 0)
09:09:600 Reading Metroid1.pak c47f49b0.PART (Offset: 0x0140a1e0 / DupeNum: 0)
09:09:607 Reading Metroid1.pak a9f745c2.TXTR (Offset: 0x0140a9c0 / DupeNum: 0)
09:09:613 Reading Metroid1.pak 60fcf8a4.PART (Offset: 0x0140b280 / DupeNum: 0)
09:09:614 Reading Metroid1.pak d494822f.PART (Offset: 0x0140b440 / DupeNum: 0)
09:09:614 Reading Metroid1.pak cb271679.PART (Offset: 0x0140b640 / DupeNum: 0)
09:09:614 Reading Metroid1.pak 0aa9c9b9.PART (Offset: 0x0140bc00 / DupeNum: 0)
09:09:615 Reading Metroid1.pak e39a22d8.TXTR (Offset: 0x0140bfe0 / DupeNum: 0)
09:09:616 Reading Metroid1.pak 3f8b0a57.CMDL (Offset: 0x0140c0a0 / DupeNum: 0)
09:09:616 Reading Metroid1.pak 44eb432b.TXTR (Offset: 0x0140c500 / DupeNum: 0)
09:09:617 Reading Metroid1.pak 5b9574a6.CMDL (Offset: 0x0140d760 / DupeNum: 0)
09:09:618 Reading Metroid1.pak b1ff00d8.PART (Offset: 0x0140d980 / DupeNum: 0)
09:09:620 Reading Metroid1.pak 90c9a703.CMDL (Offset: 0x0140dd60 / DupeNum: 0)
09:09:622 Reading Metroid1.pak 8dcc97bb.CMDL (Offset: 0x0140df80 / DupeNum: 0)
09:09:627 Reading Metroid1.pak b00da51c.TXTR (Offset: 0x0140e1c0 / DupeNum: 0)
09:09:628 Reading Metroid1.pak 026d43f5.CMDL (Offset: 0x0140e280 / DupeNum: 0)
09:09:629 Reading Metroid1.pak 0017aa7c.TXTR (Offset: 0x0140e700 / DupeNum: 0)
09:09:630 Reading Metroid1.pak a18c891a.TXTR (Offset: 0x0140ece0 / DupeNum: 0)
09:09:630 Reading Metroid1.pak f0c16d43.TXTR (Offset: 0x0140f640 / DupeNum: 0)
09:09:631 Reading Metroid1.pak e8add51d.CMDL (Offset: 0x0140f740 / DupeNum: 0)
09:09:631 Reading Metroid1.pak b9576da5.TXTR (Offset: 0x0140fc80 / DupeNum: 0)
09:09:632 Reading Metroid1.pak 415e0fd5.CMDL (Offset: 0x0140fd80 / DupeNum: 0)
09:09:632 Reading Metroid1.pak 14c1ed6d.CMDL (Offset: 0x01410260 / DupeNum: 0)
09:09:633 Reading Metroid1.pak 9b64ca6b.STRG (Offset: 0x014106c0 / DupeNum: 0)
09:09:633 Reading Metroid1.pak a6114429.TXTR (Offset: 0x01410760 / DupeNum: 0)
09:09:638 Reading Metroid1.pak 12771af0.CMDL (Offset: 0x014109e0 / DupeNum: 0)
09:09:644 Reading Metroid1.pak 0e04379f.TXTR (Offset: 0x0027b780 / DupeNum: 0)
09:09:694 Reading Metroid1.pak 9db6156c.TXTR (Offset: 0x00289800 / DupeNum: 0)
09:09:713 Reading Metroid1.pak ff5323ce.TXTR (Offset: 0x00273ee0 / DupeNum: 0)
09:09:763 Reading Metroid1.pak fe5f7b41.TXTR (Offset: 0x0027b8c0 / DupeNum: 0)
09:09:781 Reading Metroid1.pak ddf454cf.CMDL (Offset: 0x003a2300 / DupeNum: 0)
09:09:834 Reading Metroid1.pak b6dbfb19.CSKR (Offset: 0x003a2440 / DupeNum: 0)
09:09:835 Reading Metroid1.pak 19c53902.CINF (Offset: 0x00268c20 / DupeNum: 0)
09:09:881 Reading Metroid1.pak 50fde4f7.EVNT (Offset: 0x01410ea0 / DupeNum: 0)
09:09:932 Reading Metroid1.pak e3e36e22.ANIM (Offset: 0x01410ec0 / DupeNum: 0)
09:09:933 Reading Metroid1.pak cf8b40da.ANCS (Offset: 0x014127c0 / DupeNum: 0)
09:09:939 Reading Metroid1.pak 42bd30f0.TXTR (Offset: 0x01412960 / DupeNum: 0)
09:09:943 Reading Metroid1.pak 450dadff.PART (Offset: 0x01412dc0 / DupeNum: 0)
09:09:945 Reading Metroid1.pak 4ccdb634.TXTR (Offset: 0x0125a140 / DupeNum: 0)
09:10:114 Reading Metroid1.pak bb5bf8f4.TXTR (Offset: 0x01412f60 / DupeNum: 0)
09:10:168 Reading Metroid1.pak 6e8b5524.CMDL (Offset: 0x01412fa0 / DupeNum: 0)
09:10:170 Reading Metroid1.pak 05a4faf2.CSKR (Offset: 0x014148c0 / DupeNum: 0)
09:10:170 Reading Metroid1.pak 64eaefe1.CINF (Offset: 0x014148e0 / DupeNum: 0)
09:10:172 Reading Metroid1.pak e3594c19.EVNT (Offset: 0x01414a20 / DupeNum: 0)
09:10:177 Reading Metroid1.pak 2131aeda.ANIM (Offset: 0x01414a80 / DupeNum: 0)
09:10:179 Reading Metroid1.pak 88a40927.ANCS (Offset: 0x01414b40 / DupeNum: 0)
09:10:179 Reading Metroid1.pak 480fe92f.STRG (Offset: 0x01414d00 / DupeNum: 0)
09:10:180 Reading Metroid1.pak aa33cb73.TXTR (Offset: 0x01414ec0 / DupeNum: 0)
09:10:181 Reading Metroid1.pak b2165be1.TXTR (Offset: 0x014171a0 / DupeNum: 0)
09:10:183 Reading Metroid1.pak 8c76aeef.TXTR (Offset: 0x01419600 / DupeNum: 0)
09:10:183 Reading Metroid1.pak d0e78196.TXTR (Offset: 0x01419a40 / DupeNum: 0)
09:10:195 Reading Metroid1.pak 32e23a21.TXTR (Offset: 0x0141d600 / DupeNum: 0)
09:10:196 Reading Metroid1.pak 93791947.TXTR (Offset: 0x0141d960 / DupeNum: 0)
09:10:197 Reading Metroid1.pak 5fd319d9.TXTR (Offset: 0x0141f740 / DupeNum: 0)
09:10:198 Reading Metroid1.pak 83fe417c.TXTR (Offset: 0x01420780 / DupeNum: 0)
09:10:200 Reading Metroid1.pak 38273338.TXTR (Offset: 0x014229e0 / DupeNum: 0)
09:10:205 Reading Metroid1.pak 99bc105e.TXTR (Offset: 0x01422fa0 / DupeNum: 0)
09:10:215 Reading Metroid1.pak 173317bd.TXTR (Offset: 0x0142aec0 / DupeNum: 0)
09:10:216 Reading Metroid1.pak 07d6a014.TXTR (Offset: 0x0142bea0 / DupeNum: 0)
09:10:227 Reading Metroid1.pak 1f97cb69.TXTR (Offset: 0x0142e0e0 / DupeNum: 0)
09:10:228 Reading Metroid1.pak 8808da40.TXTR (Offset: 0x0142e4e0 / DupeNum: 0)
09:10:229 Reading Metroid1.pak 7c9ea950.CMDL (Offset: 0x0142ed40 / DupeNum: 0)
09:10:248 Reading Metroid1.pak 17b10686.CSKR (Offset: 0x01441120 / DupeNum: 0)
09:10:249 Reading Metroid1.pak c6ffcbb8.CINF (Offset: 0x01441180 / DupeNum: 0)
09:10:254 Reading Metroid1.pak e5ed2365.EVNT (Offset: 0x01441960 / DupeNum: 0)
09:10:258 Reading Metroid1.pak 23ebcd9f.ANIM (Offset: 0x01441c00 / DupeNum: 0)
09:10:261 Reading Metroid1.pak 98b79a27.EVNT (Offset: 0x014414a0 / DupeNum: 0)
09:10:261 Reading Metroid1.pak 7ecc3e10.ANIM (Offset: 0x01441560 / DupeNum: 0)
09:10:262 Reading Metroid1.pak 53393a1e.EVNT (Offset: 0x01441680 / DupeNum: 0)
09:10:262 Reading Metroid1.pak 91df8ba0.ANIM (Offset: 0x01441720 / DupeNum: 0)
09:10:263 Reading Metroid1.pak 5c929b85.ANCS (Offset: 0x01442040 / DupeNum: 0)
09:10:263 Reading Metroid1.pak 81d229fd.TXTR (Offset: 0x01442180 / DupeNum: 0)
09:10:264 Reading Metroid1.pak ccfe3c49.CMDL (Offset: 0x01443620 / DupeNum: 0)
09:10:265 Reading Metroid1.pak 5d370627.PART (Offset: 0x01443720 / DupeNum: 0)
09:10:265 Reading Metroid1.pak 07465b53.TXTR (Offset: 0x01443a20 / DupeNum: 0)
09:10:267 Reading Metroid1.pak 4a6a4ee7.CMDL (Offset: 0x01444fa0 / DupeNum: 0)
09:10:272 Reading Metroid1.pak c4d56026.PART (Offset: 0x014450a0 / DupeNum: 0)
09:10:277 Reading Metroid1.pak cc1a88f6.TXTR (Offset: 0x014453a0 / DupeNum: 0)
09:10:279 Reading Metroid1.pak 81369d42.CMDL (Offset: 0x01446560 / DupeNum: 0)
09:10:279 Reading Metroid1.pak 055bbfe6.PART (Offset: 0x01446640 / DupeNum: 0)
09:10:280 Reading Metroid1.pak d11fb84e.TXTR (Offset: 0x01446940 / DupeNum: 0)
09:10:281 Reading Metroid1.pak 9c33adfa.CMDL (Offset: 0x01447fc0 / DupeNum: 0)
09:10:281 Reading Metroid1.pak 2c60aa65.PART (Offset: 0x014480c0 / DupeNum: 0)
09:10:282 Reading Metroid1.pak 1a436beb.TXTR (Offset: 0x014483c0 / DupeNum: 0)
09:10:282 Reading Metroid1.pak 576f7e5f.CMDL (Offset: 0x014488a0 / DupeNum: 0)
09:10:283 Reading Metroid1.pak edee75a5.PART (Offset: 0x014489a0 / DupeNum: 0)
09:10:283 Reading Metroid1.pak d4235938.PART (Offset: 0x01448ca0 / DupeNum: 0)
09:10:288 Reading Metroid1.pak 1811b01e.MAPA (Offset: 0x03578920 / DupeNum: 0)
09:10:342 Reading Metroid1.pak 26ca1ff6.STRG (Offset: 0x010b59c0 / DupeNum: 0)
09:10:393 Reading Metroid1.pak cde604f0.MREA (Offset: 0x01470880 / DupeNum: 0)
09:10:457 Reading Metroid1.pak 0x014708e0 (0x00001040 bytes)
09:10:488 Reading Metroid1.pak 0x01471920 (0x0000f2e0 bytes)
09:10:505 Reading Metroid1.pak 0x01480c00 (0x0000dfe0 bytes)
09:10:522 Reading Metroid1.pak 0x0148ebe0 (0x0000f940 bytes)
09:10:538 Reading Metroid1.pak 0x0149e520 (0x0000ffa0 bytes)
09:10:555 Reading Metroid1.pak 0x014ae4c0 (0x0000f800 bytes)
09:10:571 Reading Metroid1.pak 0x014bdcc0 (0x0000f760 bytes)
09:10:588 Reading Metroid1.pak 0x014cd420 (0x0000fde0 bytes)
09:10:605 Reading Metroid1.pak 0x014dd200 (0x0000f9a0 bytes)
09:10:622 Reading Metroid1.pak 0x014ecba0 (0x0000e780 bytes)
09:10:638 Reading Metroid1.pak 0x014fb320 (0x0000ff20 bytes)
09:10:662 Reading Metroid1.pak 0x0150b240 (0x0000caa0 bytes)
09:10:679 Reading Metroid1.pak 0x01517ce0 (0x000072a0 bytes)
09:10:688 Reading Metroid1.pak 0x0151ef80 (0x0000ffa0 bytes)
09:10:712 Reading Metroid1.pak 0x0152ef20 (0x00000440 bytes)
09:10:722 Reading Metroid1.pak 403f2572.SCAN (Offset: 0x01448fc0 / DupeNum: 0)
09:10:775 Reading Metroid1.pak 2ef95774.SCAN (Offset: 0x014490c0 / DupeNum: 0)
09:10:778 Reading Metroid1.pak d4da7776.SCAN (Offset: 0x01449240 / DupeNum: 0)
09:10:778 Reading Metroid1.pak 69d140ee.SCAN (Offset: 0x014493c0 / DupeNum: 0)
09:10:779 Reading Metroid1.pak 58395a73.SCAN (Offset: 0x014495a0 / DupeNum: 0)
09:10:779 Reading Metroid1.pak fe4e51c7.SCAN (Offset: 0x014515e0 / DupeNum: 0)
09:10:788 Reading Metroid1.pak 3be96f49.SCAN (Offset: 0x0145b1e0 / DupeNum: 0)
09:10:800 Reading Metroid1.pak 0a65f679.SCAN (Offset: 0x01470640 / DupeNum: 0)
09:10:831 Reading Metroid1.pak e43960e0.SCAN (Offset: 0x01470760 / DupeNum: 0)
09:10:832 Reading Metroid1.pak 776c1a96.CMDL (Offset: 0x01738320 / DupeNum: 1)
09:10:949 Reading Metroid1.pak 1c43b540.CSKR (Offset: 0x0176a600 / DupeNum: 1)
09:10:949 Reading Metroid1.pak a12b691e.CMDL (Offset: 0x0356bd00 / DupeNum: 0)
09:11:015 Reading Metroid1.pak 18443363.TXTR (Offset: 0x01730fa0 / DupeNum: 1)
09:11:075 Reading Metroid1.pak 072ee1a5.TXTR (Offset: 0x035632c0 / DupeNum: 0)
09:11:130 Reading Metroid1.pak 2f415f68.TXTR (Offset: 0x0353fa00 / DupeNum: 0)
09:11:183 Reading Metroid1.pak 379a5750.TXTR (Offset: 0x035630c0 / DupeNum: 0)
09:11:231 Reading Metroid1.pak 3c2dd9c1.TXTR (Offset: 0x03544460 / DupeNum: 0)
09:11:316 Reading Metroid1.pak 423e6f40.TXTR (Offset: 0x03544260 / DupeNum: 0)
09:11:370 Reading Metroid1.pak 5e2f40e6.TXTR (Offset: 0x0353b260 / DupeNum: 0)
09:11:429 Reading Metroid1.pak 7f2a671d.TXTR (Offset: 0x03538f80 / DupeNum: 0)
09:11:480 Reading Metroid1.pak b7c9747a.TXTR (Offset: 0x03543dc0 / DupeNum: 0)
09:11:496 Reading Metroid1.pak bbf345c7.TXTR (Offset: 0x03544060 / DupeNum: 0)
09:11:496 Reading Metroid1.pak bdd7cc56.TXTR (Offset: 0x03543fc0 / DupeNum: 0)
09:11:497 Reading Metroid1.pak c69b83e5.TXTR (Offset: 0x03569b40 / DupeNum: 0)


This shows that the game basically loads resources in the same order that they're specified by the MLVL dependency list. Lines 1-53 show the game loading layer-agnostic resources (world geometry textures + the PATH file). Lines 54-142 show the game loading resources used by layer 0 (the only layer in the room). After that it loads the MAPA, then the area name STRG, then the MREA itself. After that, it loads resources that are used by the MREA but aren't specified by the MLVL list - SCAN files, models used by ANCS nodes, and the skybox model.

Some notes:
- The MLVL dependency list simply lists each resource in the order they're referenced by the MREA file - things are not rearranged for faster load times. However, the MLVL dependency list does not mirror the order of files in the actual pak.
- Some of the assets in the MLVL dependency list are skipped over - I believe those are mostly resources that are already in memory because they're being used by the room the player's coming from, or one of the rooms adjacent to it.
- There are some assets that seem to just be specified dynamically instead of being in the MLVL list, which are loaded after the MREA file. I'm guessing this is because the game will always load every asset specified by the MLVL dependency list, but some dependencies may or may not be needed (ie there's no need to load models being used by ANCS nodes if nothing in the room is actually using that node).
- The STRGs used by SCAN files are not loaded unless you start actually interacting with the scan point. Once you stop interacting the STRG is unloaded from memory.
- It looks like different groups of MREA sections are streamed in separately rather than all being loaded together.
- Not really sure how the game decides which copy of a given resource to stream in. This particular room doesn't make much use of duplicates.

In theory the goal here is to optimize two metrics: load times and total pak size. Load times would mainly be optimized by grouping together assets that are loaded together to reduce disc seeks. Pak size would be optimized by duplicating assets as little as possible. A pak completely optimized for load time would have a separate copy of every asset for every room that uses it, but that would result in absolutely massive files, so it wouldn't work very well in practice. So in theory, the main thing you need to look at is how the assets used by a particular room are fragmented. It wouldn't necessarily matter if an asset isn't stored close to the room that uses it, provided it's bunched up with other assets that are being used so a bunch of things can all be loaded at once. If the assets are too fragmented then that's when you would duplicate some files to try to bunch them up together again.

I still don't really know how you would translate this to an actual algorithm to decide which resources should go where and which resources should be duplicated in what spots, but I feel like I'm understanding the issue a lot better at least. I want the next release of PWE to be able to build new paks from scratch soon, so I'll have to come up with something to address this, and I'll probably end up going with something sub-optimal with hopes of improving it later. But if anyone else wants to jump in and help figure this out, feel free.
Antidote
Antidote
Edit history:
Antidote: 2016-07-14 10:48:14 am
Antidote: 2016-07-14 10:47:39 am
Antidote: 2016-07-14 10:46:57 am
Antidote: 2016-07-14 10:46:22 am
Antidote: 2016-07-14 10:42:56 am
Antidote: 2016-07-14 10:41:13 am
Antidote: 2016-07-14 10:40:34 am
Antidote: 2016-07-14 10:40:15 am
Antidote: 2016-07-14 10:39:54 am
Antidote: 2016-07-14 10:33:50 am
Antidote: 2016-07-14 10:33:26 am
Antidote: 2016-07-14 10:28:37 am
Antidote: 2016-07-14 10:23:34 am
2016-07-14 10:23:14 am
Actually, the algorithm writes itself, all the engine would have to do is do a diff between each of the SObjectTag entry duplicates in the pak, checking the offsets to the data, whichever is closest gets priority, also seeking forward is always faster than seeking backward,so any seek that needs to go forward will have priority over any seek that goes backward unless that reverse seek is small, e.g ~10s of KB and the forward seek is >= 1MB, I'd need to take a look at the actual code to confirm, but this is the most likely implementation retro would have chosen.

Also, the list in the MLVL is an ownership transfer list, basically the current map transfers ownership of tokens to the new map, if and only if the new MLVL area entry asks for them, also, it appears that script objects can be preserved between areas too, though I doubt this is actually used in practice.

The new map would then call the active layers touch functions, which would then issue "Lock" on all of their relevant tokens, Lock would then, if needed, load any relevant data needed in order to load the resource, which is then passed to the factory. Ultimately you wind up with a very low memory footprint, while still having near immediate access to data, this is why layer changes require you to completely reload a room in MP1, it's done simply to avoid massive Lock batches (they're not cheap).

EDIT:
Finally, CTokens behave a lot like smart pointers, except they're a lot more intelligent, each CToken contains a CObjectReference, which then contains a reference to an IObj, that IObj is what actually contains the data, in other words: you can have 5 CTokens to say, the Omega Pirate skeleton, but you only have one CObjectReference, and ONE IObj, it's a one-to-many relation all the way down the chain, and it's ridiculously scalable.
Aruki
2016-07-14 05:36:04 pm
It definitely goes down the MLVL list first, since if you look at the order things are loaded most of the dependencies of the new area are loaded before the MREA. The Touch call is probably used as a fallback for anything missing from the MLVL list and for those dynamic dependencies like the SCANs.

The thing that really confuses me is if you look at the offsets in the load output there are cases where eg the game seeks backwards just to load one single asset, then forwards again back to where it was. A lot of these are very large seeks too (>1MB) so this doesn't look like it would be optimal to me. For instance, just look at the second texture load where it loads from 0x21300, then 0x13c9960, then 0x30e40. There are lots of spots like that throughout the list.

The other issue I've got is the order of assets in the pak does not match the MLVL list/the actual load order at all, even for Exterior Docking Hangar which naturally can't use duplicates since it's the first room in the pak. I don't really know how they decided which assets to shift around. I'd assume they would shift more common assets to later in the list so they'd be more accessible to later rooms, and indeed most of the early assets are all exclusive to EDH. But then the door model is also mixed in there, which is used by most rooms.

I dunno, it's all pretty confusing to me, lol.
Antidote
2016-07-14 05:49:23 pm
I could have the direction inverted, it definitely seems that way, gotta keep in mind that GC DVDs are backwards compared to standard DVDs: the data starts at the outside edge.
JosJuice
2016-07-15 03:16:56 am
Dolphin dev
Quote from Antidote:
I could have the direction inverted, it definitely seems that way, gotta keep in mind that GC DVDs are backwards compared to standard DVDs: the data starts at the outside edge.

No, the data of GC/Wii DVDs starts at the inner edge, at least for single-layer discs and the first layer of dual-layer discs. If you run a GameCube disc through CleanRip, you will see the ripping speed increase as it gets to the later parts of the disc, which only makes sense if it's going outwards.
Aruki
Aruki
Edit history:
Aruki: 2016-07-15 08:10:03 pm
Aruki: 2016-07-15 06:42:39 am
Aruki: 2016-07-15 06:38:00 am
2016-07-15 06:37:46 am
okay, I came up with something else interesting. Since the pak is generally split up by area (all the dependencies of an MREA precede an MREA), I tried keeping track of which areas had new asset duplicates. The results are pretty interesting:

Code:
Frigate
- Emergency Evacuation Area
- Connection Elevator to Deck Beta
- Biotech Research Area 1
- Biohazard Containment
- Deck Gamma Monitor Hall
- Main Ventilation Shaft Section A
- Cargo Freight Lift to Deck Gamma

Chozo
- Main Plaza
- Ruined Shrine
- Vault
- Vault Access
- Arboretum
- Tower of Light
- Ruined Gallery
- Sun Tower
- Transport Access North
- Gathering Hall
- Hive Totem
- Watery Hall
- Dynamo
- Burn Dome
- Furnace
- Hall of the Elders
- Crossway
- Elder Hall Access
- Crossway Access South
- Reflecting Pool
- Transport to Tallon Overworld South

Phendrana
- Phendrana Shorelines
- Chozo Ice Temple
- Ice Ruins West
- Ice Ruins East
- Ruined Courtyard
- Phendrana Canyon
- Research Entrance
- Quarantine Cave
- Observatory
- Frozen Pike
- West Tower
- Control Tower
- Research Core
- East Tower
- Research Lab Aether
- Gravity Chamber

Tallon
- Tallon Canyon
- Root Cave
- Main Ventilation Shaft Section C
- Main Ventilation Shaft Section B
- Main Ventilation Shaft Section A
- Reactor Core
- Cargo Freight Lift to Deck Gamma
- Biohazard Containment

Mines
- Main Quarry
- Mines Security Station
- Elevator A
- Elite Control Access
- Elite Control
- Phazon Processing Center
- Elite Quarters
- Central Dynamo
- Metroid Quarantine B
- Metroid Quarantine A
- Elevator B
- Fungal Hall A

Magmoor
- Monitor Station
- Magmoor Workstation

Impact Crater


Almost all of the rooms that have new duplicates are medium-to-large size rooms, with a couple exceptions here and there. The vast majority of the smaller rooms don't have any duplicates, and this is even in cases where the assets are heavily fragmented and in some cases are literally on the opposite end of the pak from the rest of that area's resources (ie the second to last room in Chozo Ruins doesn't have any new duplicates, and one of the textures it loads is the very first texture in the pak, and has no duplicates). So it seems pretty likely to me that smaller rooms weren't allowed to spawn duplicate assets, probably because they generally load really quick and the increase in load time wasn't worth the extra disc space being used. How they accomplished that could've either been by the tools automatically deciding which rooms are large enough to qualify, or they could have manually flagged certain rooms as needing to be loaded quicker at the expense of disc space.

On the flip side there's a lot of large rooms (like Reactor Core, Geothermal Core, Ore Processing, Artifact Temple, etc) that don't have any duplicates and I'm not sure why not. So still some missing details I guess, or those rooms were flagged to have slower loads for some reason.

edit: Update. I guessed that duplicating assets is a lot less important than grouping assets by load order, so with that in mind I tried rebuilding Metroid2.pak with no duplicates but otherwise the same file order. The loading time for certain larger rooms (Main Plaza, Gathering Hall, Watery Hall, etc) are substantially (4-5 seconds) longer, but the vast majority of the load times are still perfectly fine, particularly for smaller rooms and rooms that have a lot of time to load. Even if a per-area flag isn't how Retro did it, that idea makes a lot of sense to me because there are a ton of rooms that just plain don't need duplicates. This is probably the implementation I'll go with for PWE.
Antidote
Antidote
Edit history:
Antidote: 2016-07-19 08:36:01 pm
Antidote: 2016-07-19 08:35:37 pm
Antidote: 2016-07-19 08:04:08 pm
2016-07-19 07:47:20 pm
Jack and I have put quite a bit of effort improving our Texture Coordinate Generation(TCG) support, and Jack has put the final bugs to bed, now we have full Retro style TCG, every UV mode should now work perfectly. What makes this special is that we're not using Retro's data to accomplish this at all, we're using a custom macro language provided by hecl which allows us to generate shaders for any backend much more quickly than translating it from TEV setups. And this is the result:


EDIT:
And to demonstrate how simple the macro language is, here is the entire setup for both materials used by that model:
Code:
HECLOpaque(((Texture(0, UV(0)) * Lighting()) + (Texture(1, RetroUVMode0NodeN(Normal())) * Texture(2, UV(1)))))
HECLOpaque((((Texture(0, UV(0)) * Lighting()) + Texture(1, UV(1))) + (Texture(2, RetroUVMode0NodeN(Normal())) * Texture(3, UV(2)))))
Antidote
2016-07-21 01:06:05 pm
Just found something interesting and weird: Palettes in TXTRs have dimensions. Why I will never know, C8 textures use a 256x1 palette, while C4 textures use a 1x16 palette.
wowsers
2016-08-07 12:11:59 pm
Quote from Parax:
The biggest change though is how the objects themselves are put together. It seems like objects are now referred to in the code as Game Object Components, and they aren't standalone anymore - each component seems to now explicitly represent one part of an object rather than an entire object in itself. Then there's one object type which is structured completely different from all the other ones, called just GameObject. GameObject components have no connections and no properties; they have a list of sub-components, then a bool (probably Active) and position/rotation/scale. The interesting thing is a lot of the component types are just the same ones we know from the older games (Relay, Timer, Counter, etc) but there's some new ones that are extremely generic, like Render, Static Collision, Health, among others. I'm hesitant to jump to conclusions without fully verifying it, but the impression I get is you can basically make your own objects by assembling the components you want and attaching them to a GameObject. If that's the case, then that makes the engine a lot more flexible, and I already really liked how flexible it was in the older games, heh.


That sounds so similar to how Unity 3D handles objects it's scary, in Unity you have a GameObject with a transform property where you can then access the objects components from, they can really be any arbitrary thing you want to happen.
Antidote
2016-08-07 05:28:21 pm
Component based programming predates Unity by a fair bit, Unity was just the first to provide it in a tidy package.
wowsers
2016-08-08 10:13:56 am
Yeah, the earliest real example I know is .NET, which would make sense as Unity's main programming language is Mono which is based on .NET
And that SHOULD enable people to create their own custom objects.