 |
| Register | Login | |||||
 |
Main
| Memberlist
| Active users
| Calendar
| Chat
| Online users Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album |
|
| | ||
|
| Register | Login | |||||
|
Main
| Memberlist
| Active users
| Calendar
| Chat
| Online users Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album |
|
| | ||
| Acmlm's Board - I3 Archive - - Posts by Guy Perfect |
| Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
| User | Post | ||
Guy Perfect                   Since: 11-18-05 Last post: 6302 days Last view: 6301 days |
| ||
Originally posted by FreeDOSI assure you that it is. By what evidence did you come to your conclusion? |
|||
|
Guy Perfect Since: 11-18-05 Last post: 6302 days Last view: 6301 days |
| ||
| Will do.
For the most part, I'd say anything that creates a descent assembly of human-created source code quaifies as a "good" tool to use. After all, any programming language out there ultimately becomes opcodes for a processor. I don't see why any variant of any specific language could end up being "inadequate" in that sense. The only real issue is what the language allows the developer to do. If it's too restrictive, then a language may be unwieldy. That's not the case with FreeBASIC, though. While there may be some kwirks that some languages have (such as Class support) that FreeBASIC doesn't do, there isn't really a restriction in the capabilities of the language itself (since there's technically no such thing as an object when it comes to ASM). |
|||
|
Guy Perfect Since: 11-18-05 Last post: 6302 days Last view: 6301 days |
| ||
| Looks like all the GL calls are happening in the correct order... But for each of the things you mentioned after "on startup," you didn't show the exact syntax of what you were using. Do that, and a problem may be discoverable.
A way to verify if the texturing works is to input a simple shape by hand and set the texture coordinates by hand. If THAT works, then there's something in the way you're calling the vertex arrays that's not working correctly. Also, as a rule of thumb, two triangles can be rendered faster than one quad. I recommend using GL_TRIANGLE_STRIP instead of GL_QUADS for your glBegin and glDrawArrays statements. |
|||
|
Guy Perfect Since: 11-18-05 Last post: 6302 days Last view: 6301 days |
| ||
| Compound assignments are not allowed in VB. What you have going is this:
DestX = DestY = 0 The first = is understood to be an assignment, but the second = is understood to be equality. The equivalent of what you're saying, in C, is "DestX = DestY == 0;", which isn't what you want. All you end up doing is setting DestX to True, not 0. Numerically, this would mean that DestX = -1. So when you say "For x = destX To destX + 1", you're actually saying "For x = -1 To 0" To correct this problem, seperate the two statements like this: DestX = 0: DestY = 0 All VB data types (except for Byte) are signed, so &HFF00 is actually -256 since 16 bits fits in an Integer variable and gets converted to signed thusly. Use the typecasting character & after the hex number to force the compiler to interperate the literal as a Long and not an Integer. Doing so will yeild the value 65280, which is what you will need for your bitwise calculations. Use it in this form: &FF00& Additionally, the way you're using it is "And Not &HFF00"... This may be done to combat the negation, but if not, you could use "And &HFF" to get the same result. The math you're using for the destination X and Y of BitBlt is a bit incorrect. What you have is this: (x * 8) + 1, (y * 8) + 1 Where what you want is this: (x + 1) * 8, (y + 1) * 8 This will ensure that tiles are blitted on an 8-pixel boundary. What you had was only moving the destination by 1 pixel in each direction. If I understand correctly what you're trying to do, you want to read the tile at the (X, Y)th index in the source DC. The code for that you have is as such: Tile1 \ 8, Tile1 Mod 8 I don't know if this is correct or not, but instinct tells me you're probably gonna need something else. I suggest this: (Tile1 \ 8) * 8, (Tile1 Mod 8) * 8 I also feel that use of the Integer Division operator is somewhat extraneous, so I recommend using Int(Tile1 / 8) * 8, but that's your call. For blitting, use SRCCOPY instead of SRCAND, since a straight blit with SRCAND will only look correct on a white background. You're calling the locations of the coordinates from a file buffer and incrementing the accumulator by 3 plus the current pass number, as such: Counter = I + 3 What you probably want to do is have it read data sequentially from start to finish. And since you're reading 4 tiles, you'll need to compensate for 4 bytes. Thus, you should increment the counter by 4 each pass: Counter = Counter + 4 The reason your tiles are blitting diagonally is because you're incrementing DestX and DestY at the same time: DestX = DestX + 1 DestY = DestY + 1 In order to go from left to right, top to bottom for 1024 bytes (assuming a square map), you would have to have 32 passes for Y, and within there, 32 passes for X. Like this example: For Y = 0 To 31It appears as though your tiles are being copied in 2x2 squares to the destination, so your loops would have to compensate for that with a little extra math: For Y = 0 To 30 Step 2 To sum it all up, I've prepared a tentative drawing routine for you. I do not know if this will work properly, as I cannot test it. But even if it doesn't, you have something a little more tidy to work off of: Samp(0 To 1023) ' There's data in here already (edited by BGNG on 01-30-06 10:19 PM) |
|||
|
Guy Perfect Since: 11-18-05 Last post: 6302 days Last view: 6301 days |
| ||
| You realize that I mentioned "a huge pain" would only occur without careful planning, right? I'm confident in saying that programmers encountering huge pains from the perspective of actual coding could probably revise their methods a bit.
But I digress. "Huge pains" are not on the topic of "When is it approperiate to withhold source code" (edited by BGNG on 01-30-06 10:14 PM) |
|||
|
Guy Perfect Since: 11-18-05 Last post: 6302 days Last view: 6301 days |
| ||
| Could you post a screenshot showing the problem? | |||
|
Guy Perfect Since: 11-18-05 Last post: 6302 days Last view: 6301 days |
| ||
| Looking at the code again, there should be a full 256×256 image blitted to the destination DC. Looking at the picture, that's not how it is.
An easy way to verify if things are working correcly is to add the following line: Tile1 = 0: Tile2 = 0: Tile3 = 0: Tile4 = 0 Before the line: 'Blit tiles ...That should cause the same tile to be drawn over and over again. Try that, and tell me if it works or not. |
|||
|
Guy Perfect Since: 11-18-05 Last post: 6302 days Last view: 6301 days |
| ||
| If it did draw the same tile over and over with that suggestion, then the image blitter is working properly and there's a problem with your TSA data or perhaps how you're loading it into the source picture box. (Perhaps the \ 8 and Mod 8 should be 16's instead of 8's?) | |||
Guy Perfect Since: 11-18-05 Last post: 6302 days Last view: 6301 days |
| ||
| As I've been mentioning since the beginnnig, withholding source code and releasing only documentation encourages people to look into the ROM using the knowledge they have and see what they can do. If the knowledge they have access to already exists in program source code, then why look into the ROM if what you would do is already sitting in front of you?
For general utilities that can be used to locate data in any ROM out there, such as a corrupter or text search utility, source code should be distributed because they benefit nearly everyone involved towards the cause. For specific utilities that hack games that perhaps have specifically not been hacked in the past, source code will dilude the motivation to further understand the workings of the game. And there's some people who just take source code for the sake of having it. The ability to spawn a utility from something they neither understand nor care to ever look at seems to strike a chord with a great many people, and that's not anything at all what ROM Hacking is about. ↑ See that paragraph? Describes something about source code that is counterproductive towards the goal of ROM Hacking. (edited by BGNG on 01-31-06 03:24 PM) |
|||
|
Guy Perfect Since: 11-18-05 Last post: 6302 days Last view: 6301 days |
| ||
Originally posted by DischI don't feel that the benefits of knowing the intricacies of a game will typically come from looking at the source code. "cnmeerr = nins(0x67430, 0x6E3F0, 0x800D43F0, cnme[ i ]);" doesn't necessarily mean "Write next course name to deallocated ROM space" to most people. Originally posted by DischThis is where ideology comes in. Do not assume that everyone aspires to the same things. I personally feel that ROM hacking is not about "production," but about "capability." Who cares how many editors and mods are churned out by people? I don't, for one. What matters is that people have the capability to move on to bigger and better things, being able to make great works with what they know and can do. One more Super Mario Bros. hack is inconsenquential. A Super Mario Bros. hacker moving on to Yoshi's Island is more significant. And I don't mean by use of editors, either. If they have the skills to begin hacking more and more sophisticated games, then the ROM Hacking community has played its role. One more editor doesn't make that happen, so its source code will not help much. You also mentioned the throwing away of "experience, information and work," which I feel is exagerative. All three of those things are provided by, for example, releasing an editor with documenation and without source code. The experience of the person allowed the game to be hacked and the editor to be made. The documentation provides the application of this experience as well as any information needed to do so. The work is the editor, which is provided as proof of concept. Does it matter if people have the source code? Not if understanding and skill are the focus of the mission. Source code provides little to that end. Originally posted by BGNGIf the source code is there, and application of the understanding provided by the documentation is already implemented, then there is little reason to look into things any further. With just documentation, however, a working model will have to be created by research and experimentation. Is that more work? Yes, it is. Does it mean people gain a greater understanding and more experience? Yes, it does. It sounds rather lazy to me for people to request source code for ROM hacking when documentation is provided. Originally posted by DischIt is wasteful. And they may never hack the game at all if they have some arbitrary editor's source. They are more likely to do so given documentation and no source. Originally posted by DischYes, hack ROMs. Not use editors, not play with someone else's source code, but hack ROMs. Given documentation of how to hack, people will gain a better understanding of how to hack. Given an editor's source code will likely remove any ambition for using the documentation in the first place. It's apparent that people aren't willing to do work. They don't care about the "why" behind things; only the "what." They just want their toys so they can make stuff and feel special. Is this the idea you intend to exp Originally posted by AilureNot quite. Linux is an original piece of software intended to provide many people with positive capabilities. ROM hacking, being about technique and understanding, does not rely on software to do anyone's bidding. Documentation, on the other hand, provides the understanding in written form. Originally posted by AilureLike I said, people tend to care about the "what" and not the "why." If they end up coming up with something good, they'll keep it to themselves to promote their own egos as well as draw attention to themselves. Those activities don't matter to me, and I won't support them. If anyone wants to be a better hacker, they'll do it by learning, not by trying to make something to use as a leverage of power against everyone else. |
|||
|
Guy Perfect Since: 11-18-05 Last post: 6302 days Last view: 6301 days |
| ||
| Classes were invented for the sake of productivity, not program efficiency. They may make certain styles of programming easier on the programmer, but add more overhead and ultimately make the program run more slowly than if classes were not used.
I fully encourage people to use whatever language they're most comfortable with. But with FreeBASIC, I'm simply inquiring if it alleviates some of the nasty feelings people have towards the BASIC language because of what Microsoft has done with it. |
|||
|
Guy Perfect Since: 11-18-05 Last post: 6302 days Last view: 6301 days |
| ||
| I agree. That's why I feel that releasing documentation is more effective than source code. Those who want to learn will learn. I don't see anything that source code can do that can't be fully explained in a document. After all, there's a reason for everything, and the reason for something in source code may not be apparent. (edited by BGNG on 01-31-06 05:03 PM) |
|||
|
Guy Perfect Since: 11-18-05 Last post: 6302 days Last view: 6301 days |
| ||
| Considering FreeBASIC is barely a year old and has almost every feature C does, I'd say it's quite a feat to behold. | |||
|
Guy Perfect Since: 11-18-05 Last post: 6302 days Last view: 6301 days |
| ||
Originally posted by DischThen the cause of confusion between us is a miscommunication of what we understand ROM hacking to be. I understand it to be getting, not putting, but getting data from ROMs and figuring out what it does. Music, graphics, levels, etc... Anything really that has to do with editing, that's just generic game modding to me. If source code that I release is adjusted for the purpose of game modding, then I would feel violated as if someone cut off my hand and played Badminton with it. For F-Zero X, I'm making the editor for two reasons: to share tracks and to provide a decent benchmark for N64 hacking. The track file format for shaing doesn't even need to have ROM-patching capabilities, so there's no need for source code there. To promote hacking--hacking as I understand it to be--the source code is next to worthless because all the theory and memory addresses can be contained in a written document. Originally posted by Hyper LOLDocumentation is not limited to ROM hacking. There can be other documents for other things. Why consult a ROM hacking document for help with File I/O? Originally posted by Hyper LOLHence the term "relative." That ensures that, say, "right" is only "right" from the perspective of the object's facing direction. Like I said, this is a simple trigonometry concept, but it requires an advanced understanding of trigonometry to come up with a way to implement it. The reason you don't see much information on it is because anyone with some college-level math ought to be able to come up with their own way to do it without much effort. Until such a time that I can provide such an article, look up information contaning all three of the words "azimuth," "elevation" and "skew" (edited by BGNG on 01-31-06 09:02 PM) |
|||
|
Guy Perfect Since: 11-18-05 Last post: 6302 days Last view: 6301 days |
| ||
| Oh, I see what you mean. That's an easy fix. Come to think of it, that's probably what DestX and DestY were for.
Yeah, just define some arbitrary values for X and Y translation and add them to the destination X's and Y's when you blit. That will enable you to put the data anywhere you please. "X * 8" will become "X * 8 + DestX" and so-forth. Here's Tentative Drawing Routine Take 2. Just change the values of DestX and DestY to move the final blitting coordinates: Samp(0 To 1023) ' There's data in here already (edited by BGNG on 02-04-06 10:21 AM) |
|||
|
Guy Perfect Since: 11-18-05 Last post: 6302 days Last view: 6301 days |
| ||
| All in a day's work. And I'll pass on the beta-ing. I've got enough going on here on my end that more probably wouldn't work out too well. (edited by BGNG on 05-01-06 04:35 PM) (edited by BGNG on 05-01-06 04:35 PM) (edited by BGNG on 05-01-06 04:37 PM) |
|||
|
Guy Perfect Since: 11-18-05 Last post: 6302 days Last view: 6301 days |
| ||
| Three versions of the ROM, VL-Tone. You're using the North American, aren't you?
To anyone else, that means you'll be wanting a "Super Mario 64 (U) [!].z64" for the patch. |
|||
|
Guy Perfect Since: 11-18-05 Last post: 6302 days Last view: 6301 days |
| ||
Originally posted by DischAs I said before: Knowledge is nothing if it is not applied. Have documentation and not use it, might as well not have documentation. Have documentation and learn how a game works, you can apply those concepts to other games or make an editor or teach a flock of geese or whatever. Have source code and see how a program works (maybe), and you have source code that compiles into a program. No geese involved. 1) Power, ego, status symbols... Any use of source code for those things is negative. I don't see anyone saying "Look at this new document I have! Wait, no... don't look at it, it's mine... But then I can't prove that I have it! What am I gonna do to show you how awesome I am?" 2) Uniquness is not equal to greed. If UserA makes a program and UserB modifies it by adding some new features and slaps his own name on it, then all it is is UserA's program with new features and UserB's name on it. Each programmer working on his own unique project will ensure that there aren't a billion variants of the same thing. 3) If you had the source code for an intuitive level editor, would you take the time to make your own version of the code that's already there on your hard drive? Chances are, you'd flat-out use some of it. Making it all means that you have a full understanding of everything your work does. That's not necessarily true when you copy/paste source code. There's always a chance one of those lines of code was X + 0 instead of X + 1 and you didn't notice it. That's understanding that you would have had if the source code was not there. 4) "But to understand the source... wouldn't they already have to understand the workings of the game?" Yes... yes, they would. Documentation therefore has a higher precedence for learning and understanding than source code. But if the source code is there, who will honestly try to figure it all out? Anyone who will use the documentation, you say? Then the source code isn't even necessary. 5) "It may not all be applicable to ROM hacking -- but it's still knowledge/understanding/skill bulding." Why would it be placed in the ROM hacking community if it wasn't used for understanding of ROM hacking? That's like a pumpkin pie made with sweet potatoes... not a pumpkin pie. 6) With this is the mindset of "All the work has been completed. I need not do anything." While not everyone will do that, it's still there. Withholding source code prevents it. 7) Credit goes to some guy called Bram: theta = cutoff*2*pi / samplerateYou know what that is? If you have some background with audio DSP, you can probably figure that there's code for a high-pass and low-pass filter there, but the real meat and potatoes is that it's specifially a One-zero IIR implementation. How does it work? I have no idea. How was it made? Not a clue. There's NO way I can tell you that just by looking at the source code, even with my background in the field. I don't know how it was created, but I sure as heck wish I did... Some documentation would come in handy right about now. Needless to say, source code does not necessarily supply sufficient information for understanding as does documentation. All things considered, the final scores for desirability of release are Documentation: +170; Source code: -10. That's just a scant -10, but it's more than 0, so there's still reason to withhold it. The benefits that simply aren't there in source code are contained in documentation. Still, lots of people tell me that source code might as well be released. Well, I have a -10 saying it shouldn't, and documentation more than makes up for it. |
|||
|
Guy Perfect Since: 11-18-05 Last post: 6302 days Last view: 6301 days |
| ||
Originally posted by DischYou just shot yourself in the foot. I give you a reasonable example to support my statement and you ignore it because it's not what you wanted to hear. It's obvious you aren't the least bit interested in understanding why I feel the way I feel and you will, as you have been doing, simply post things that say "I disagree, BGNG. Try harder" without any real reason other than the fact you disagree. Originally posted by DischLooking back at the previous posts of the thread, I'm reminded of this one. Turns out it was you who said that. Same thing as above, you took a statement of mine and said "I disagree, therefore you are wrong." If you were hoping to retain any bit of credibility, Disch, you shattered your dreams into tiny ilttle shards. Originally posted by XkeeperI'll keep that in mind if I ever get the idea to do so. The purpose of this thread was to exp Speaking of which... If you're gonna moderate, you might as well go back and delete that "BWAHAHA" post as well as the "OMG IT'S LONG POST DEBATE TIEM" one before locking the thread or moving it to The Pit of Dispair. I'm fairly certain spam and flaming aren't allowed. I will make no further replies to this thread. If anyone wishes to speak with me on the subject, use a PM. |
|||
|
Guy Perfect Since: 11-18-05 Last post: 6302 days Last view: 6301 days |
| ||
| The exact reason there are a lot of modifications released for Super Mario Bros. likely involves a newcomer to the field of ROM hacking and they're eager to show others what they were able to do. While this may become tirelessly redundant for people who have watched this happen countless times in the past, it's a perfectly reasonable thing to do for someone who is new to the whole idea and I don't have a problem with that.
After all, constructive feedback is invariably helpful and if a person picks up some Super Mario Bros. tools to help become acquainted with ROM manipulation, then all the power to him. As has been mentioned already, it's a familiar game with simplistic features and several tools exist to work with it. It's a game of choice to work with to get into this stuff, so that could explain why people start with it. And in order to get feedback, they'll have to release some work which, for obvious reasons, end up taking the form as a new Super Mario Bros. patch. Now don't get me wrong: If a person ends up releasing upwards of 10 patches for Super Mario Bros., then some problems will arise. But if you see 10 Super Mario Bros. mods each by different authors, it shouldn't be any cause for concern. As a person's exposure to ROM modding expands, he will tend to take on various other challenges and enter the territory of games that most people wouldn't care to look into themselves. It's all part of a simple learning curve. So I see the multitude of Super Mario Bros. projects to be a good thing, as it means there's a multitude of people gaining interest in the activity and perhaps some great mod for a great game will be released by one of them in the future. |
| Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
| Acmlm's Board - I3 Archive - - Posts by Guy Perfect |
