 |
|
Main
| FAQ
| Uploader
| IRC chat
| Radio
| Memberlist
| Active users
| Latest posts
| Calendar
| Stats
| Online users
| Search
| |||
| Views: 88,491,786 |
Main
| FAQ
| Uploader
| IRC chat
| Radio
| Memberlist
| Active users
| Latest posts
| Calendar
| Stats
| Online users
| Search
|
04-27-24 08:45 AM |
|
| Guest: Register | Login | |||
| Main - Posts by Parasyte |
| Parasyte |
| ||
 Red Goomba Level: 18 Posts: 21/48 EXP: 24788 Next: 5109 Since: 02-09-09 From: Flagstaff, AZ Last post: 5211 days Last view: 5189 days |
The only thing it has in common with web browsers is that it is capable of displaying images. :x
I know, I've already violated one of the most important rules to new open source software start-ups (proof). One of the problems I face is requiring users to download a 7MB runtime just so they can do something silly like open a ROM so they can see the level renderings which are already uploaded to my website. (See OP.) For Ubuntu users, it's a piece of cake: XULRunner 1.9.0 is installed by default. Users only need to download the gz/bz2 from hgkw, and run a simple command:
For Windows and Mac OS X users, it's not so trivial. Either the user must download XULRunner, or Firefox (which has its own "private" XULRunner included). The other options for Windows users include: 1) creating a XULRunner package (XPI) that can 'installed' to the XULRunner environment by double clicking the icon, 2) creating a full executable [classic] installer, complete with a XULRunner build, if necessary; this is how XR apps like SongBird currently do it. Truth is, I'm still not entirely familiar with the platform, so it's hard to say what's the best way to make an installer. |
| Parasyte |
| ||
|
Red Goomba Level: 18 Posts: 22/48 EXP: 24788 Next: 5109 Since: 02-09-09 From: Flagstaff, AZ Last post: 5211 days Last view: 5189 days |
Nothing to report, exactly. I haven't forgotten about this project. Just not seen any new community interest in it... |
| Parasyte |
| ||
|
Red Goomba Level: 18 Posts: 23/48 EXP: 24788 Next: 5109 Since: 02-09-09 From: Flagstaff, AZ Last post: 5211 days Last view: 5189 days |
RT-55J: That sounds about right. Mega Man 7 is not one of my favorite games, either. I haven't tried the debugger in bsnes; in fact, I only heard about it yesterday. (I've been keeping myself busy with other things for quite a long while.)
Kiokuffiib11: It doesn't do much. It can only draw stages in their first palette, and shows the location of objects on the map. If you got that far, yes that's really all there is. Also, it only supports the US v1.0 ROM. |
| Parasyte |
| ||
|
Red Goomba Level: 18 Posts: 24/48 EXP: 24788 Next: 5109 Since: 02-09-09 From: Flagstaff, AZ Last post: 5211 days Last view: 5189 days |
Props, Daiz. I like the idea of throwing out the old [level format] and bringing in the new. In fact, I like it so much, I'm almost inclined to believe it was my idea.  |
| Parasyte |
| ||
|
Red Goomba Level: 18 Posts: 25/48 EXP: 24788 Next: 5109 Since: 02-09-09 From: Flagstaff, AZ Last post: 5211 days Last view: 5189 days |
Remember kids, every time you use the term "TSA", God kills a [potentially awesome] ROM hacker. This message brought to you by: http://www.kodewerx.org/wiki/index.php/Syndrome#Compression
So here's the deal: the popular term "Tile Squaroid Assembler" ("TSA") doesn't make any sense. As mentioned in the link above, "Squaroid" is not a real English language word. Not mentioned in the link, the encoding method is useful outside of tile placement. It is optimized for 2-dimensional data arrays (like images), but is also commonly implemented with 1-dimensional data for text compression (many a ROM hacker/translator is familiar with this). It can even be expanded to further multidimensional arrays. The problem here is one of convention; the name is bad, and needs to be changed to something that makes sense. Alternatives such as "Map 16" make even less sense in the grand scheme; the Mega Man series game engines use multiple levels of this encoding method to reference not only 16px x 16px pieces of an image, but also 32x32, 256x256, and a final arbitrary size (that of the complete stage; which is almost never a perfect square). "Map *" is a bad name for these reasons, not to mention the argument for multidimensional data encoding as stated above. It's hard to say what the encoding method is really called. Most notably, and at its most basic, it is simple array indexing. Suggestions, anyone? Edit: Fixed the link and expanded form of the acronym. |
| Parasyte |
| ||
|
Red Goomba Level: 18 Posts: 26/48 EXP: 24788 Next: 5109 Since: 02-09-09 From: Flagstaff, AZ Last post: 5211 days Last view: 5189 days |
I can see the logic behind "metatile" and "block" used to describe the encoding method. They tie in well with 2D arrays, but not much else. |
| Parasyte |
| ||
|
Red Goomba Level: 18 Posts: 27/48 EXP: 24788 Next: 5109 Since: 02-09-09 From: Flagstaff, AZ Last post: 5211 days Last view: 5189 days |
Too bad CAN'T HACK METROID AM GOAL didn't stick... |
| Parasyte |
| ||
|
Red Goomba Level: 18 Posts: 28/48 EXP: 24788 Next: 5109 Since: 02-09-09 From: Flagstaff, AZ Last post: 5211 days Last view: 5189 days |
Perhaps the question you should be asking is, why?
The only difference between a 6-digit Game Genie code and an 8-digit code is that the latter includes a data checking (condition) parameter. The data check helps to ensure the code output is only sent to the console when the proper ROM bank is loaded. So ... If you have a 6-digit code that is working, why bother turning it into an 8-digit code? It's not like its a dumb processes (able to be done by a simple program/algorithm) anyway; you still need to know the correct input byte from the original ROM bank. If you are already aware of all this, you should have also known that any Game Genie encoder/decoder is just the tool you need; Paste the 6-digit code, you'll be given the raw (address ? condition : data) format. The (condition) will be blank, of course, so fill it with the input byte from the proper ROM bank, and convert it back to a Game Genie code. Simple, no? |
| Parasyte |
| ||
|
Red Goomba Level: 18 Posts: 29/48 EXP: 24788 Next: 5109 Since: 02-09-09 From: Flagstaff, AZ Last post: 5211 days Last view: 5189 days |
Posted by Jigglysaint Uh yeah, that's what I said. Didn't mean to make it sound like the comparison was for ROM bank numbers (since there is no general [easy] way to get that information in hardware). Sorry for any confusion. Posted by born2partyPosted by Parasyte I don't understand that; possible ROM addresses? There are two ways to look at ROM in a bank-switching computer (like NES): 1) As a complete ROM chip; just one large file. 2) The same way a CPU with limited address space sees it; in smaller pieces, usually only 1 or 2 banks at a time. In the former interpretation of "ROM addresses", each address references only a single byte. This is simple; you see files in this light all the time. In the latter interpretation, you realize that a CPU address of something like $8000 can be remapped in hardware to point to different banks within the ROM. On the other hand, address $E000 [likely] cannot be remapped at all, and so it can only reference a single byte in a single bank. This was a short lesson, and much important information was left out. But the gist is simple: the lack of the comparison parameter in a Game Genie code does not inherently make the game less stable or cause more crashes. There is a high probability that they will be less stable, yes. But do not take this as canon. How do you know if you need the comparison parameter? Well, that depends on the mapper used in the game you're working with. Some mappers have 16KB of ROM space "hard wired" at $C000-$FFFF; any Game Genies address that falls within that range do not require the comparison parameter. Other mappers have 8KB "hard wired" at $E000-$FFFF. And yet others have the full 32KB of ROM space "hard wired" ($8000-$FFFF). As for how you actually use the comparison parameter after it's determined to be necessary... well, I assume you know the data byte you're intending to replace with the code; that data byte is what you put into the comparison parameter. Here is an example: Assume, for a moment, that you just debugged your favorite game and found an "LDA" instruction (opcode: $A9,$xx) that loads the number of lives you start with. In this case, the $xx might be $03... Anyway, you want to replace the $03 with something a little more fun, like $32 to start with 50 lives. Now assume the address of this instruction is at address $D5F3, and that the mapper uses an 8KB "hard wired" bank (at $E000-$FFFF). Since the address does not fall within the "hard wired" bank, using the comparison parameter is a good idea. The opcode at $D5F3 is $A9, so the $03 must be at $D5F4; you will use that address for your Game Genie code. Six-digit format = D5F4 : 32 Eight-digit format = D5F4 ? 03 : 32 Does that make sense? The only difference is the "? 03" -- which came from the original instruction:
|
| Parasyte |
| ||
|
Red Goomba Level: 18 Posts: 30/48 EXP: 24788 Next: 5109 Since: 02-09-09 From: Flagstaff, AZ Last post: 5211 days Last view: 5189 days |
Posted by MathOnNapkins Close; the only non-square shapes that can be built by this method in the Mega Man series are the maps (stages) themselves. However, the point stands that it can be used to create non-square shapes; I attempted to cover this in the original post, referencing multidimensional arrays. The indexing/hash table method can be used to create lines, rectangles, cubes, cuboids (yes; this one really is a word), or hypercubes, to list just a few. Naming it after shapes is hopeless... Just one simple name, that's all it needs. Not a context-sensitive, situation-dependent series of names, evoked when the term fits the bill. That's why I've been trying to use terms like "hash table" and "array indexing"; but these are not quite descriptive enough. Short of that, "TSA" and "Map *" hurt my grammatical-oriented mind. |
| Parasyte |
| ||
|
Red Goomba Level: 18 Posts: 31/48 EXP: 24788 Next: 5109 Since: 02-09-09 From: Flagstaff, AZ Last post: 5211 days Last view: 5189 days |
Speaking of confusion, the "HOA" acronym is typically used to refer to Home Owners Associations, which are evil by association (excuse the pun).
Posted by MathOnNapkins Nor this. (You can tell I work in IT.  )
Also, I argue that column-based game engines (Super Mario Land, Legend of Zelda, ...) are just using 1-dimensional variations of the same concept. Considering it to be something different for that attribute alone is kind of silly. That would be like calling all of the different LZ variants by names that don't include those two letters; Wikipedia's list includes: LZ77/78 · LZSS · LZW · LZWL · LZO · LZMA · LZX · LZRW · LZJB · LZT · ROLZ. Imagine if another variant was called something ridiculous like "Reduced Sliding Window Mapping algorithm; RSWM" ... Sure, the name might fit what the algorithm *does* but it does not describe the algorithm *family*. |
| Parasyte |
| ||
|
Red Goomba Level: 18 Posts: 32/48 EXP: 24788 Next: 5109 Since: 02-09-09 From: Flagstaff, AZ Last post: 5211 days Last view: 5189 days |
Something to the tune of "Layout Sets", "Layout Groups", or "Layout Classes" ...
I think the term "layout" accurately describes the method of arrangement, without being overly verbose. Avoiding the term "tile" is a good thing, because it could be applied to sets of vectors in 3-dimensional space, just as easily as it is applied to sets of tiles in 2-dimensional space. Avoiding the term "map" is also a good thing, since "maps" are also typically thought of as using a 2-dimensional coordinate system. |
| Parasyte |
| ||
|
Red Goomba Level: 18 Posts: 33/48 EXP: 24788 Next: 5109 Since: 02-09-09 From: Flagstaff, AZ Last post: 5211 days Last view: 5189 days |
As the author of RLM, I'm never told of any bugs that people encounter with it. (The main complaint, actually, is that users can't figure out how to run it. LULZ!)
However, I have heard that hacks making use of HDMA cannot be properly unlocked by RLM. Apart from this random claim (made about two years ago, as I recall) I have no evidence that this is actually a problem. My question for you all, has anyone ever seen a case of an unprotected hack which cannot be opened properly in Lunar Magic, or run properly in an emulator? And more importantly, can anyone provide an example hack where this actually happens? I'll be glad to investigate and fix any bugs. What I won't do is write a freakin' GUI for the program, because it would just be a window with a single button that says, "Unlock" ... most pointless GUI ever! Though I could change the semantics on the command line arguments to allow accepting only an input file name; in the case that an explicit output file name is not given, a new file name will be implicitly chosen. At the least, that will enable users to drag their locked ROM onto rlm.exe within their file manager, and it will "Just Work". Thoughts? |
| Parasyte |
| ||
|
Red Goomba Level: 18 Posts: 34/48 EXP: 24788 Next: 5109 Since: 02-09-09 From: Flagstaff, AZ Last post: 5211 days Last view: 5189 days |
Pwnd. |
| Parasyte |
| ||
|
Red Goomba Level: 18 Posts: 35/48 EXP: 24788 Next: 5109 Since: 02-09-09 From: Flagstaff, AZ Last post: 5211 days Last view: 5189 days |
This is the post in question (which claimed HDMA was responsible). Again, I have no idea where this information originated, or what kind of evidence is available to support it. Also, it wasn't posted two years ago, like I thought. But 10 months ago.
http://jul.rustedlogic.net/thread.php?pid=101233#101233 Is anyone actively looking into these RLM bugs? I've got some "leads" in this thread, but no hard evidence, yet. EDIT: "Panic in the Mushroom Kingdom" 1 & 2 are definitely broken when unlocked. I see RLM version 1.3 on the horizon... EDIT 2: I've located the bug that causes graphic corruption, and released RLM v1.3 today: Downloads New in this release: v1.3 (12-26-09): * Fixed yet another last-known-problem with (what I believe is) "Super ExGFX". * Support for drag-n-drop (see "Using RLM"). * Readme cleanup. This fixes "Panic in the Mushroom Kingdom" 1 & 2 (and probably a lot of other hacks). With that said, are there any problems that v1.3 doesn't fix? |
| Parasyte |
| ||
|
Red Goomba Level: 18 Posts: 36/48 EXP: 24788 Next: 5109 Since: 02-09-09 From: Flagstaff, AZ Last post: 5211 days Last view: 5189 days |
It's a stretch to claim that writing assembly is "slave labor" (it never caused any revolts or revolutions when developers were using it just perfectly well up until the mid-90's). Besides, you don't have to know a thing about assembly for writing your own games for SNES. Use the C language.
Not everyone is cut out to write their own operating system... (Which is exactly what you're doing when you're writing a game engine!) |
| Parasyte |
| ||
|
Red Goomba Level: 18 Posts: 37/48 EXP: 24788 Next: 5109 Since: 02-09-09 From: Flagstaff, AZ Last post: 5211 days Last view: 5189 days |
Posted by Aaendi There's still money in game development today, and there's still no revolts or revolutions. What's next? "C/C++ programming = slave labor?" |
| Parasyte |
| ||
|
Red Goomba Level: 18 Posts: 38/48 EXP: 24788 Next: 5109 Since: 02-09-09 From: Flagstaff, AZ Last post: 5211 days Last view: 5189 days |
I'm sorry, but, this is a horrible idea. If you can't program/hack around the inherent system limitations, give up! Don't go "fixing" it by emulating hardware that didn't exist. And for that matter, don't go "fixing" it by creating new hardware just so it can be emulated.
*sigh* |
| Parasyte |
| ||
|
Red Goomba Level: 18 Posts: 39/48 EXP: 24788 Next: 5109 Since: 02-09-09 From: Flagstaff, AZ Last post: 5211 days Last view: 5189 days |
There was a similar project called "Ultimate Mortal Kombat Trilogy" which also requires a customized emulator to play. Once it gets to that point, you might consider writing a modern game, instead of hacking one for old hardware that can't faithfully reproduce your vision.  |
| Parasyte |
| ||
|
Red Goomba Level: 18 Posts: 40/48 EXP: 24788 Next: 5109 Since: 02-09-09 From: Flagstaff, AZ Last post: 5211 days Last view: 5189 days |
You're right; other CPUs have other architectural flaws. |
| Main - Posts by Parasyte |
© 2005-2023 Acmlm, blackhole89, Xkeeper et al. |
|
MySQL - queries: 133, rows: 165/165, time: 0.223 seconds. |