 |
| Register | Login | |||||
 |
Main
| Memberlist
| Active users
| ACS
| Commons
| Calendar
| Online users Ranks | FAQ | Color Chart | Photo album | IRC Chat |
|
| | ||
|
| Register | Login | |||||
|
Main
| Memberlist
| Active users
| ACS
| Commons
| Calendar
| Online users Ranks | FAQ | Color Chart | Photo album | IRC Chat |
|
| | ||
| Acmlm's Board - I2 Archive - - Posts by Dish |
| Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 |
| User | Post | ||
Dish Spiny Level: 38 Posts: 161/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| *Disch kicks self upon further research... I see there's a NOTSRCCOPY option which does a normal inverted blit. So you could replace the 2 bitblt calls with a single one using NOTSRCCOPY. I must have just missed that one before or something... egads.  |
|||
|
Dish Spiny Level: 38 Posts: 162/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
Originally posted by HyperHacker If you want to save a ShowWindow() call, you can or WS_VISIBLE with your window styles to make the window visible as soon as it's created. WS_VISIBLE | WS_OVERLAPPEDWINDOW <-- will give you a lot of the typical window features and will be visible right away.
I'm not sure of a way, actually. What I would recommend is creating a log file or something on startup then write strings to it with fprintf(): #include <stdio.h> FILE* pDebugFile = fopen("C:\\debuglog.txt","wt"); fprintf( pDebugFile, "This will be put in the debug file\n" ); fclose( pDebugFile ); fprintf can do all the string formatting that printf does (%d, %X, and all that good stuff)
printf() <--- prints to the default iostream (I think... not quite sure exactly how printf works) fprintf() <--- does same, but writes to a file sprintf() <--- does same, but writes to specified buffer (this is what you want) char some_string[80]; sprintf( some_string, "This will be put in some_string" ); again.. same string formatting that printf does |
|||
|
Dish Spiny Level: 38 Posts: 163/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| Erm... no offense man... but did you even try to look at any of the documentation that came with Flash? The tutorials and stuff that come with it are idiot-proof. You're asking how to do stuff like adding a link to your homepage button... which you could probably figure out just by looking at the GUI. Flip through the help files... do some actual research. The help files and demos that come with the program are going to explain it much better than anyone here will be able to (since they're way more interactive). Then ask questions when you get stumped. |
|||
|
Dish Spiny Level: 38 Posts: 164/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| Could you be more specific? Typically if you want to change a color in the palette just click on the color you want to change and select a new one. |
|||
|
Dish Spiny Level: 38 Posts: 165/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| Well I haven't used Flash MX, but I have Flash 5... and it certainly isn't hard to find the demos. They're right there in the Help menu. I doubt they were moved/removed for Flash MX. If he's asking about doing simple animations and simple buttons... I doubt he made any effort into looking in any of the help files. Perhaps he could have worded it better... like "does anyone know of a place I can get tutorials on how to use Flash MX"... then I might not have responded before  . But the way he asked his question sounded like "I want to make this movie, someone do all the work for me" |
|||
|
Dish Spiny Level: 38 Posts: 166/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| Usually, but not always. They may end with a JMP command, and a routine may contain several RTS commands (some of which may be skipped by branching). Typically though... for small routinse... yes, it'll end with an RTS and usually start right after an RTS. This is no real 'rule' though... it's just a common trend. | |||
|
Dish Spiny Level: 38 Posts: 167/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| Following up JSRs isn't really all that important.... at least not from my experience. The routine being jumped to will almost always return in one form or another (either by doing an RTS, or JMPing to another routine that RTS, or something similar). The only way a JSR routine wouldn't return is if the return address is pulled from the stack... something like: JSR someroutine someroutine: PLA PLA ;ditch return address RTS though code that does that isn't exactly common. So I wouldn't beat yourself up for not noticing JSRs. Chances are they won't affect the routine you're looking at. |
|||
|
Dish Spiny Level: 38 Posts: 168/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| There are only 4 sprite palettes available for use in battle in FF1. While it is technically possible to add more... it's more work than I feel like explaining right now (and it'd probably go over your head a bit). So for now.. .just accept that you only have 4 palettes available for battle sprites. Since there's only 4 palettes... and there's 12 classes (6 unpromoted, 6 promoted), there's obviously more classes than palettes... so classes will have to share palettes with each other. This is why when you change colors in one of the palettes, several classes are affected (several classes use that palette). No make matters even MORE restrictive... only 2 of the 4 available palettes are "safe" to use without side-effects... since battles in FF1 use sprites for things other than the party, it needs palettes for those things as well. The 4 palettes are layed out: 1) Classes (tan, brown, light blue) -- normally used by BB, Thief, BM, etc 2) Classes (red, white, 'skin') -- normally used by Fighter, RM, WM, etc 3) Animation (no real default) -- labelled with "Varies" in Hackster. Used by battle animations 4) Cursor/Stone (white, light grey, dark grey) -- labelled with "Cursor" in Hackster. Used by the battle cursor and classes which have turned to stone. Palettes 1 and 2 are safe to use for your classes. Palette 3 is used whenever a weapon/spell is drawn on the screen... and it's changed to reflect the colors of that weapon/spell. So this palette is pretty much completely unavailable for your needs (unless you want to have a class who's color is always changing in battle). You might be able to use palette 4, but if you change it, the cursor will change colors. Also, classes that are turned to stone get switched to this class... so a class that uses this palette normally will not look any different when turned to stone. Also there are some other weird things... like the fading out effect in the inn will not work for classes which use this palette. So yeah... basically you're stuck with just those 2 palettes for all 12 classes. |
|||
|
Dish Spiny Level: 38 Posts: 169/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| I can't really get into specifics because I find cout/cin to be horrendously stupid (look into printf() and scanf() for better alternatives unless you absolutly have to use cout/cin like for your school or something). Your 'name' variable should probably be a character array... not a single character nor a 'string' type: char name[80]; // will hold up to 79 characters (plus null termination) I would assume cin would give you the entire string typed by the user... but can't say for sure... I dodged cout/cin like the plague when I was learning. |
|||
|
Dish Spiny Level: 38 Posts: 170/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| hmm... just tried it and got the same deal. gets() might be what you want for this... I just tried: char name[90]; printf("Input name:\n"); gets(name); printf("%s",name); it worked as expected, even with spaces. edit: haha... apparently you already figured it out ;D (edited by Disch on 11-05-04 08:43 PM) |
|||
|
Dish Spiny Level: 38 Posts: 171/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| HyperHacker: Yeah that should be working. Just make sure your TargetString is a large enough buffer to hold the entire string (plus null terminator). Cellar Dweller: What is snprintf()? And why do you recommend it over tried-and-true sprintf()? my MSDN searches came up with nothing, and it doesn't seem to be part of stdio (didn't work when I tried to compile it). I'm of the impression that "if it ain't broke, don't fix it"... and sprintf certainly isn't broke. sloat: while it's true that you won't NEED a debugger... it can really make the difference when tracking down those really nasty buggers. Simple breakpoints alone are a wonder at tracking down exactly where your flaw is on a program crash... and variable viewing is beyond invaluable (you -could- print the vars in question in a messagebox... but seeing the result of one var may warrant you to check another... and without a debugger you'd have to stop, recompile, re-run, etc.. and in the process tacks a lot of code that can be really ugly when you forget to remove it all --which I've done in the past XD) |
|||
|
Dish Spiny Level: 38 Posts: 172/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| ah yeah... good call about the fgets. *Disch grumbles at command-prompt programming |
|||
|
Dish Spiny Level: 38 Posts: 173/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| 1) DTE is short for Dual Tile Encoding... a common method of simple compression. Typically... 1 byte represents one character, but many games use DTE methods to have 1 byte represent 2 characters (or even more, in the case of MTE). FF1 can use DTE to compress most of its text (basically everything except whatever is displayed in battle). There are copies of both the regular table file, as well as a table file which contains DTE information floating around for FF1 (some are included in the FFHackster download) However, since character names are displayed in battle, you should NOT use DTE when making default names (if you do they will be distorted in battle). Any docs that said you should must have been referring to class names (ie: "Fighter", "Black Belt", etc) which are never displayed in battle. 2) If I'm not mistaken... the same doc that explains how to expand names to 5 characters also explains how to add default names (I forget the link to those docs... are they listed in the first post in this thread?) 3) This would be a lot more work than you may be thinking. Most of the game revolved around there being a fixed number (4) of characters in the party. If you want to cut it down to 3 you'll have to do a lot of hunting and change a lot of stuff. Shop routines, clinics, all the menu screens, a bunch of stuff in battle, treasure chest opening routines.... everywhere that the game does something which interacts with the individual characters in the party would potentially need changing. Needless to say this would be a fairly large hack to complete. |
|||
|
Dish Spiny Level: 38 Posts: 174/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
Cellar Dweller: for some reason I didn't think to search google. Thanks for the links, even though I found your post to be somewhat condescending Originally posted by HyperHacker What you have to understand, is that the compiler does not compile the project. It compiles a single .cpp/.c file. Therefore, it is impossible for the compiler to know a function exists unless it comes across the declaration while it's parsing the file. You can think of #include lines as copying the included file and pasting it in the .cpp file right at the #include line. From what I'm understanding of your problem... you're attempting to use a variable before it's declared. For example: somevar += 4; //this will generate errors, since somevar isn't defined until the next line int somevar; what you're probably donig in your program is similar (mind you I'm guessing... correct me if I have it wrong): --------- #include "main.h" #include "cpu.h" HWND hWindow; -------- Now.... if you think back to what I said about #including being kind of a copy/paste deal... anything in main.h and cpu.h is found by the compiler BEFORE hWindow is declared... so hWindow is invisible in those files. If you switch things around and put the hWindow declaration above the #include lines, then it will solve your problem (note: for this .cpp file only! see below). But this is sloppy sloppy sloppy. If you have functions in main.h and cpu.h that work with a window... pass the HWND to the function as a parameter. Do not rely on global variables for this kind of thing. Now... another problem associated with global vars is, while they work well in a single .c/.cpp file, complications occur when there's several .cpp files that want to use it. For example... if you compiled two or more .cpp files, both of which have 'HWND hWindow;' declared, they would compile just fine... but when you link them together, you'll get errors (this is a similar error to what you would get if you give the same function two bodies in two different .cpp files... the reason behind the errors is similar, too). This is where the whole 'extern' business comes in. 'extern' isn't like a magic keyword to make global vars work... what it really does is tells the compiler "do not actually make this variable because it will be filled in by the linker". This is the same kind of logic as declaring functions without a body. If it would help to understand, you can think of 'extern' variables as body-less variables.. and normal variables as having a body. If you can understand why it's problematic for a single function to have two bodies, then conceptually, you should be able to understand why it's problematic to have a single variable with two bodies. But again... I still recommend against using global vars. If you need a variable in another function, it's usually better to pass the variable in question as a parameter to the function rather than having them all use the same globals. |
|||
|
Dish Spiny Level: 38 Posts: 175/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| erm.... I already replied to this in the other thread on this very board. And yeah @ Dan. I think neotransotaku got things mixed up. I've always know DTE to be 1 byte = 2 characters. |
|||
|
Dish Spiny Level: 38 Posts: 176/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| I'm not sure exactly what you're getting at... You could do 2-dimensional arrays.. like for example: int some_array[4][50]; here, some_array[1][49] would be identical to/interchangable with some_array[0][99] Or if you're just looking to change the origin (which I don't see why you'd need to), you could do a pointer trick: int some_array[50]; int *some_ptr = some_array - 50; here, some_array[0] would be the same as some_ptr[50] (changing your origin from zero to 50). But this is bad practice.... since it will produce an extra indirection (slightly slower) and I think compilers are smart enough to optimize something like "some_array[ index - 50 ]" so that the implied subtraction never really takes place. |
|||
|
Dish Spiny Level: 38 Posts: 177/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| *Disch shrugs basically the same thing. I was always under the impression that DTE = dual tile encoding , and what you described was MTE (mutli-tile encoding). But as far as I'm conserned, the 2 terms are pretty much synonymous and both yours and Dan's description basically state the same thing. |
|||
|
Dish Spiny Level: 38 Posts: 178/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| Any game can be hacked. What game are you talking about? What system is it for? This question was about as vague as you can get... how did you expect any kind of real answer? ;P |
|||
|
Dish Spiny Level: 38 Posts: 179/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
Originally posted by drjayphd It doesn't prohibit DTE in battle... it just doesn't enable DTE in battle. For general, run-of-the-mill text output in FF1, there is no conversion. So when the game reads $99 for the letter 'P'... it doesn't think "okay, this value is $99, so output the letter 'P'". Instead, it just outputs the raw value $99 as the tile number(without any checking [except for null termination] or conversion). It just so happens that the 8x8 tile which represents the character 'P' is stored at tile ID $99 For DTE to work... the game has to check each value to see if it's a DTE code character... and it if is, it has to load 2 extra bytes and output them. This not only means that the routine to load the text takes a bit longer (which isn't really that big of a deal)... but also that the routine takes up more space (which is the big problem). AFAIK, the game has 2 (or more) text loading routines... one which is 'minimized' (used in battle... DTE not supported), and one which is used for menus (and possibly dialogue and stuff). Both routines [presumably] appear in different banks... so either the game is unable to swap in the needed bank to run the DTE routine... or they just didn't think to do so. Anyway... you probably could work around getting DTE supported in battle. If you find out where both routines are and simply cut off the battle's routine and have it hop to the other routine (of course this will entail bank-hopping, which means you'll probably have to free up some code in the 'master' bank which is always a pain). There might be complications, too. The menu screen doesn't draw the text directly to the screen... it writes it to an area in RAM first, and is later drawn to the screen (maybe the battle routine won't work that way for some reason?).
'If' statments (conditionals), must be in every programming language... ever. There's simply no [practical] way around them (and yes... 6502 has conditionals... they're sometimes referred to as branches) So yeah.. you could figure out when the game is loading the battle and have it check for certain battle ID numbers to load a different song when you want. Could be a relatively simple hack. The hard part would be squeezing in a new song. |
|||
|
Dish Spiny Level: 38 Posts: 180/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
Originally posted by neotransotaku A waste of space? ZING nah I have no idea. EDIT: ahahahaa... oh yeah.... UTF-16 whoops XD (edited by Disch on 11-08-04 01:07 PM) |
| Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 |
| Acmlm's Board - I2 Archive - - Posts by Dish |
Do I have to actually show it?
)