 |
| 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: 141/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
Originally posted by Shooblilnil I should point out... you're patching the ROM... not the emulator. Don't be applying the IPS to the emulator, or you'll break it. |
|||
|
Dish Spiny Level: 38 Posts: 142/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| Common misconception here. NSFs are NOT normal music files. In fact... they're not even music files at all. They're completely self-contained executables, which contain 6502 code that gradually writes to audio registers to produce changing sound (aka music). The concept of the relationship between NSF and NSF players is similar (if not identical) to the relationship between NES ROMs and NES emus. NSFs are just stripped down ROMs which [ideally] contain only music related code/data (however, sometimes incomplete rips often contain PPU and other unneeded stuff as well, which NSF players ignore). That said... inserting an NSF into a ROM is not a simple copy/paste deal. That'd be like trying to copy paste not only level data from one game to another... but also the code which runs to load and display that level data  .Now it's not -impossible- to put an NSF in a ROM (in fact... i made an NSF from scratch and inserted into FF1 as a project a while back). You might be able to put the NSF in a big chunk of unused space in the ROM and have the game interact with the new NSF code instead of the old music code every frame (but to do this, you'd have to have a pretty decent grasp of 6502 and NES architecture and you'd have to be pretty familiar with the game you're working with). However, even this has problems... since NSFs use RAM just like full ROMs... and if the NSF tries to use RAM that the game is using for something else... the music won't play right and the game will be messed up and probably even crash. (In my project... I custom built the NSF to use RAM I knew to be unused in FF1) Now you might be thinking "okay, what if I don't copy the code, but just the music data from the NSF to the ROM?". Well that won't work either, because each game stores its music data differently... and each engine is built to play notes a certain way. Again I'm going to relate this to trying to copy/paste level data from one game to another. You might be able to get away with it in 2 games which were coded by the same guy, but 9999 times out of 10000, it just ain't gonna work. And it definatly won't work if you're using an NSF which was made by a convertion tool. So basically... what you're wanting to do is possible. But unless you REALLY know what you're doing, you're better off finding how MM2 music data is stored and editing it by hand. And yeah... it's going to be a pain in the ass (which is why there's so few NES music hacks). (edited by Disch on 10-23-04 06:40 PM) |
|||
|
Dish Spiny Level: 38 Posts: 143/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| I'm positive Rockman: Exile was done by recomposing the music and inserting the data by hand (ie, without using any other NSFs/SPCs/etc, without simple copy/pastes). Putting in music from other games is no easier than putting in your own music (except of course for the extra work that comes with composing your own music)... I mean it's the exact same process for putting in music, regardless of where the music is coming from. To take this road... follow up on those links Jaspile posted. Or try to decipher the music format on your own. (edited by Disch on 10-23-04 07:56 PM) |
|||
|
Dish Spiny Level: 38 Posts: 144/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| Well I'm gonna butt in here to give my 2 cents... even though it's pretty late in the discussion. To get this out of the way: Metroid: Zero Mission [MZM] is superior to Metroid: Fusion [MF]. However, neither quite stack up to their predecessor, Super Metroid [SM]. Note: I haven't played Prime... so whenever I make references to the entire series... assume Prime is excluded. Now to explain why: What makes the Metroid series what it is... is the feeling of exploration. Finding your way though a mysterious maze filled with baddies. It isn't really an action shooter. If you're looking to just run through a straight level and blast things as you go... you'd be better off playing Contra, or Metal Slug... or one of the other million games like that. Havnig said that... Metroid is non-linear by nature. The original tossed you in the middle of a planet, with no direction of where to go. You had to find the items you need, and explore to find the right paths to take. Every Metroid game afterwards followed suit (it is the theme of the series, afterall)... EXCEPT for Fusion. Which really took a lot of the flavor out. Now let's look at what Fusion does to the game. First of all... you're no longer exploring a dark and mysterious alien planet. You're on a freaking space station. What the hell kind of fun is 'exploring' a space station... I mean really. They tried to give each area themes so it kind of seemed like you were exploring... but the atmosphere that existed in all other Metroid games just wasn't there... which made the game feel really shallow. Secondly... Fusion does the absolute WORST thing you can do in a game. The put in manditory cutscenes which take forever that you have no way of bypassing or even skipping. I swear I want to punch every single coder/designer that puts that crap into games. Now i know it's part of the experience to read the cutscenes, which I do, and I enjoy them.... the first time I play. After that, you don't want to read them anymore... I'll never understand why games force you to. Now... a lot of people confuse these cutscenes for plot... then they say Fusion had the best plot of the series (again; excluding Prime). The cutscenes do NOT add more story to the game.... I mean read them. They ALL either consist of: "X has infected this monster -- go to this area and stop it" ... or "This powerup is ready -- go to this area and retreive it" Of course the game stretches those sentences across 10 or 20 pages so you have to wait 2 minutes to sort through them. The SA-X was a nice way to enhance the plot (and just to add a cool villain). But, really... the plot in MF is comparable to the plot in every other Metroid game. No better, no worse. Third... MF went out of its way to make sequence breaking (and thus, free exploration) impossible. This is probably the biggest downside to the game. It completely strips ALL exploration right from the game. The only things you really have to search for are hidden items... the path is completely linear up until the very end, where you're finally given some freedom. And worst of all... you have to take the exact same path every single time you play the game. This gives a big hit to the replay value of the game... as well as going against almost everything the Metroid series is about. I probably made MF sound worse than it is... a lot of that was me ranting. Really, MF is a fun game. But due to its several shortcommings, it doesn't match up to SM or MZM. I want to start MZM off by saying: MZM is nothing like the original Metroid. Those of you that are saying it's a clone or a copy or "based on" must not have played MZM... or must not have played Metroid 1. The only thing the 2 games share is the plot... which MZM really twists beyond recogniztion near the end. MZM also gives Samus more of a backstory (which it does with ONE SKIPPABLE cutscene)... when all Metroid 1 did was reveal "omg Samus is a woman!". Zero Mission got a lot of things right. They corrected a lot of mistakes they made with MF, but also kept some of the good ideas MF brought to the table. It was designed extremely well, outlining a path for the casual player to follow... but also allowing the player to freely explore -- and (as someone else pointed out), sequence breaking was really in mind when they were designing the levels. You are given SO much freedom in this game, it's unbelievable. Overall... MZM was really a top-notch game... I was really happy to see that MF didn't permanently damage the series. |
|||
|
Dish Spiny Level: 38 Posts: 145/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| If your goal is to learn assembly... start with assembly. I voted for 6502, since it's probably the easiest to learn thing listed... although z80 might be more straight-forward. Concepts introduced in higher level languages (like C/C++, and even Java) are sort of masking what the machine is really doing. For example... pointers in C/C++ can be difficult to understand at first... whereas indirect addressing in assembly (the low level equivilant) is relatively simple. To further make my point... you can learn simple assembly languages from a refernece sheet of opcodes... and maybe 6 or 7 pages of tutorials/documentation. To become a competant C/C++ coder, you'll need a lot more than that. People can read books and take coarses and still not have a full grasp at what each aspect of the language is/does. On the plus side... once you learn assembly... you'll get the basic programming concepts... so picking up higher level languages will be much easier. If your goal is to learn 6502 and you start with something higher like C/C++, you'll be learning a lot of unnecessary stuff that doesn't apply to assembly... which'll just further you from your goal. (edited by Disch on 10-25-04 09:16 PM) |
|||
|
Dish Spiny Level: 38 Posts: 146/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 If you're comparing NES specific 6502 programming to PC C/C++ or Java programming, I couldn't disagree with you more. On a simple system like the NES, everything is known. There is ALWAYS 2k of RAM, there is ALWAYS 256 bytes of stack space, the processor speed is ALWAYS constant, and every NES will run the program the same way. On a modern PC (or even a really old PC), there are a lot of variants, since the PC is built to be expandable. When programming something for modern PCs, you can (and I have) make a program that works fine on your own computer, but then when you hand it off to someone else, it doesn't work at all. There are a lot more unknowns your program will have to account for, and therefore programs become much harder to manage. Now granted... since Java programs run through a yukky VM and not actually on the computer, Java might do a better job of "shielding" those unknowns from the coder. Debugging asm is no harder than debugging other code.. it all depends on which tools you're using (and FCEU would work fine for NES specific stuff). Commentless Java or C++ code can be just has hard to follow (or even harder to follow) as commentless 6502. Originally posted by Atma X Well for starters... you won't need a disassembler.... you'll need an assembler x816 is popular, as is ca65.. although ca65 can be someone of a pain to set up... so starting with x816 is probably the way to go. I don't have links, but there's problably something on NESdev. If not, you can google it and it'll probably pop up right away.I think there are some tutorials on NESdev by GBAGuy which I guess are good (haven't looked at them, really, but I hear people talk about them a lot). You'll probably want a copy of NEStech -- don't be intimidated by its large file size... the only things you'll have to worry about for now are the memory map portions (for both CPU and PPU) and the register descriptions near the bottom. And finally, there's a fantastic reference page here, which covers all 6502 instructions and addressing modes. And of course don't be shy about asking questions around here. Myself and other 6502 goons would be glad to answer any Qs you get. I'd recommend starting with a simple program that doesn't draw anything... just have it change the background color every frame... you should be able to do that in under a page of code. |
|||
|
Dish Spiny Level: 38 Posts: 147/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| Well the bottom line is... the concepts are going to have to be learned no matter which language he chooses. Programming fundamentals are the same (or very similar) regardless of the language you use.. the only real difference is the syntax. And since his ultimate goal is to learn 65816... he's better off learning the concepts as they apply to assembly. 65816 is basically an 'upgrade' to 6502.. so by starting with 6502 (which is very simple), he'll learn pretty much everything he'll need to know right off the bat. When he makes the move to 65816, all he'll have to do is familiarize himself with a handful of new instructions/addressing modes. If he starts with C/C++ or Java, most of the things he'll be learning will not apply at all to 65816. Yeah... he'll get programming concepts and fundamentals... but that will just as easily come from coding in 6502. And typically... coding in 6502 (while more limited) is a lot simpler. There's what... under 60 instructions? Most of which are basically the same things as others (LDA vs LDX, BMI vs BPL), and some of which are borderline useless (BRK). There are WAY more than 60 operators/keywords and weird funky rules that don't apply to assembly that you'll have to memorize if you take the C/C++ route... and I'm sure it's the same for Java. If he were shooting to learn a higher level language, I'd agree that he should start with something like C/C++... but since he'll have to drop most of the info when he switches to asm, it doesn't make a lot of sense for him to start there in this case. Atma X: if you do decide to take the asm route... you might want to pop in #consoledev on irc.esper.net. Myself and a few other people kind of idle in there and are willing to teach/assist/help people with this kind of stuff. (edited by Disch on 10-27-04 05:48 PM) |
|||
|
Dish Spiny Level: 38 Posts: 148/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
Originally posted by Atma X Well it's a commandline app. Pretty much every assembler/compiler is going to be. There won't be an interface... you'll have to pass the files you want assembled in the commandline (there should be a readme with it that explains how to specify files). If you want to see the error it's giving before shutting down... open a command prompt window from Windows (Start | Program Files | Accessories | Command Prompt on my 2k machine) and run the exe from there. It's probably saying that you're not specifying any files to assemble or something. But you might be getting a memory error (I had that same problem when I tried to use it). Someone told me to right click on the exe and allow more memory to the app... they said that would fix it, but I haven't used x816 since then so I don't know if that really works or not. It probalby does. Note that before you actually run the assembler, you're going to need to have some code to assemble =P. You'll probably going to have to be doing your coding in Textpad, Metapad.... or (yuk) Notepad. Anyway... once you get the idea of how to use x816, you can make a batch file so make the process easier. Experience with C++ will help with assembly... but experience with assembly will help with C++ as well. Whichever one you want to start first will be fine. =) |
|||
|
Dish Spiny Level: 38 Posts: 149/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| That looks basically like an app to do the work of a batch file... but more restrictively =P Just type in your text editor whatever you would normally type in a commandline... such as: cd C:\Some Directory\ compiler.exe file_to_compile.asm -options pause and save it as whatever.bat. Then just doubleclick on it when you want to build. |
|||
|
Dish Spiny Level: 38 Posts: 150/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
Originally posted by Atma X Before you look into nestech... you should have the basic understanding of 6502. I'm going to assume you know the basic LDA and STA instructions... if you don't concentrate more on the 6502 end before you look into NES specific stuff (NEStech doesn't cover any 6502 stuff... it's all NES-specific hardware stuff). A CPU 'read' is when the CPU reads a value from somewhere and does something with it. For example... the LDA instruction reads a value and puts it in the Accumulator. A CPU 'write' is just the opposite... it takes a value and writes it to somewhere in memory (or to a register). STA does just this... it takes whatever is in the Accumulator and writes it somewhere. $2005 is an address, yes... but its the address of a PPU register. PPU registers are how your program interacts with the PPU (picture processing unit - graphics... basically you need to interact with PPU registers to do anything relating to video). $2005 is the Scroll register. So when you write a value to $2005, you're setting the horizontal/vertical scroll for the screen. I wouldn't worry about scrolling just yet... since it's one of the harder areas.
Well... have you been able to assemble anything yet? Maybe just get anything assembled first... even garbage code. I might be able to help more, but it's awkward doing this on a message board  ---EDIT--- http://www.geocities.com/disch_/demo.zip A little demo I made which just cycles the background color every frame (may induce seizures! XD). One file has the source with very few comments. Another has every little thing commented and explained (with the exception of wait-for-vblank stuff... I didn't want to explain how that worked just yet... status flags and branching and whatnot are arguably the hardest part of 6502, so I figure get the basics first). A binary file which contains the needed iNES header, and a batch file to build the thing is included. Hopefully it'll help. Lemme know if you have problems building the .nes file (although, the batch file should really take care of it) or if you have any other questions.
Well it's an IRC server, you'd need an IRC client. If you get mIRC, you can connect to irc.esper.net and join the chat channels on there. (edited by Disch on 10-29-04 08:42 PM) |
|||
|
Dish Spiny Level: 38 Posts: 151/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| Depends. If the game uses CHR-ROM swapping, you'll have to figure out where in the code the game loads the bank number to swap in those graphics, and change the value so that it swaps to a different bank. It might be as simple as: LDA #$[[[bank number here]]] JSR CHR_Swap_Routine Finding that code might be difficult... and even the code itself might be more complicated. You might try finding it by setting breakpoints on CHR swapping registers and watching for when the game swaps in the bank you want to change... then backtracking the code until you find where the change needs to be made. If the game uses CHR-RAM it's a bit more difficult... although the idea might still be the same. At any rate... I doubt the game in question uses CHR-RAM, (for reasons I won't get into ;D) |
|||
|
Dish Spiny Level: 38 Posts: 152/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 what's so hard about #include? what do you mean by string handling? strings are the same as arrays. There are several easy ways to change/edit/manipulate strings in C that don't require much effort or are even difficult to learn. And the API isn't part of the language... it's part of the OS. Granted... the Windows API isn't the easiest thing in the world to pick up, but once you get the idea it's not really that hard to work with. Anyway, the API is something every [decent] language is going to have to interact with.... unless the langauge is so high level that it doesn't really compile to executable code (Java), or unless the language goes out of its way to take functionality from the coder (VB)
I'd agree, that while the resources/tools for GB/Z80 aren't as common, Z80 is probably easier to pick up for a beginner.
ew, ew, ew, ew, EEEEWWWWWW VB is absolutely wretched in every aspect. Sluggish, dependancy heavy, Windows specific, with syntax that looks like absolute hell. VB is like the language for people that want to make programs... but don't really want to know how to program. I'd even recommend Java over VB. They're both stupid in the same ways... but at least Java is cross platform. (sorry HyperHacker... but I feel compelled to intervene whenever I see anyone actually recommending VB). |
|||
|
Dish Spiny Level: 38 Posts: 153/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
Originally posted by Coby Umm.... I think it's the exact same sound engine There's interpolation on by default though. Something must be wrong with their routines because it distorts a lot of the instruments and really muffles the overall sound a lot. Anyway, Go to the Config page for in_gsf and turn off interpolation... it should sound just like VBA then. Now if they could just get rid of the horrible grainyness/fuzz that VBA has... it'd be perfect. It's like listening to songs on an old worn out tape deck. |
|||
|
Dish Spiny Level: 38 Posts: 154/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 Well... I guess that depends. Basic C syntax isn't hard to learn at ALL. In fact... there's way fewer keywords you have to be familiar with. From what I've seen of VB... it uses unnecessary keywords everywhere when a simple symbol would suffice. It's almost as though they tried to make the language as though you were talking to the computer (which doesn't make it any easier, because you still have to memorize the exact right way to "say" it) "Dim MyVar As Int" <-- VB "int MyVar;" <--- C So while it may be harder to make a functional program with C... learning the C language isn't really that difficult at all.
Including files is the only logical way a compiler could know what you're doing. You can't use functions/variables that don't exist... and the compiler can't know they exist until it comes across them in code. You #include files which have the function declarations so the compiler knows "okay, SoAndSo is a function". VB really just goes out of its way to hide the benefits of including files. Instead... it just automatically includes all the regular VB stuff... but all the stuff in the API isn't part of that VB stuff... so when you want to use API stuff (like BitBlt), you can't just #include the file that contains it... you have to redefine the function in your own code. I can't even phathom the logic behind that. Declare Function GetLastError Lib "kernel32" Alias "GetLastError" () As Long <--- afaik, the VB version to re-declare a single function from the API so you can use it in your program. (again note the excessive and unnecessary use of keywords everywhere). vs #include <Windows.h> <--- In C, gives you nearly every function in the API. And I don't know what you're talking about with that bloated EXE size. Have you looked at VB apps? They're enormous.... even if you ignore the hundreds of extra DLL files and OCX files you need to run them... I mean seriously... open one up in a hex editor. The function names and variable names are stored in the binary. There's no reason for that. Plus... any decent C compiler (and every C compiler I'm aware of) drops unused functions from the code. If you include a file and don't use anything in it... there's no penalty to the program other than it taking a little longer to compile.
Properly written C will compile on any compiler. You'll have to adjust the library linkage when you build, but it's usually just a manner of minor changes (often times, just a matter of changing the file extension of the libraries you're linking to).
strcpy( strA, strB ); // <--- copy strB to strA strcat( strA, strB ); // <-- append strB to the end of strA strlen( strA ); // <-- retreive the length of strA strcmp( strA, strB ); // <-- compare 2 strings to see if they match (case sensitive) strcmpi( strA, strB ); // <--- ditto, case insensitive I don't really see what the big deal is. And as a special bonus... C gives you direct access to the memory which holds the string, which makes it MUCH easier to do string maniupulation you can't easily do in VB.
The short answer: "If you don't like it, then don't code for Windows" The long(er) answer: The API is a necessary evil even in VB. Any VB program that does any kind of serious work uses the API... because the VB methods just don't cut it. And really... the API isn't all that bad. It's a little hard to learn because there's so many parts to it, but once you get the concept down, it's really simple and straightforward (a few oddities aside).
VB automates a lot of aspects of coding... which is why it appears easier to learn. But ultimately, you end up thinking VB's methods are how things are actually happening. It's like a false truth. Anyone that wants to move from VB to something else (which you will HAVE to do if you're at all serious about programming) will have to 'unlearn' a lot of the crap VB got them used to. Actually...from your comments, I'm going to use you as an example ;D. You seem to have some weird idea that #includes and strings are overly complex... when they're really VERY simple once you understand what they are and how they work. But since you're used to VB, you don't [seem to] really understand what the purpose of including is... or why strings have to be handled a little differently from vanilla ints. VB just makes up its own unique crazy way of doing things that are so far beyond abstract... that languages that do things the right way quickly become unfamiliar. Which brings me back to my earlier comment: "VB is like the language for people that want to make programs... but don't really want to know how to program." Using VB to program is one step above using RPGMaker to 'program'... unless you do your work in the API... in which case you'd be better off (and have a much easier time) with a different language. So yeah... VB is a terrible bane to many aspiring programmers. It ultimately just makes the process of learning to program that much longer (learn the wrong way first... before unlearning it to learn the right way). Which is why I butt in whenever I see it being recommended. Telling people to start with VB is doing them a disservice... it'll just make things much much harder for them further down the road. (edited by Disch on 10-31-04 01:39 AM) (edited by Disch on 10-31-04 10:33 AM) |
|||
|
Dish Spiny Level: 38 Posts: 155/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 What are you smoking? I wrote a Full Game in 80k -- and about 40k of that is due to graphics (there's a 40k non-compressed bitmap built into the exe)
You must have missed a paragraph I said earlier, so I'll restate it: Plus... any decent C compiler (and every C compiler I'm aware of) drops unused functions from the code. If you include a file and don't use anything in it... there's no penalty to the program other than it taking a little longer to compile. When you #include files, you're typically just including a bunch of declarations. The function bodies themselves lie in libraries on the computer (like in the Kernel) and are NOT built into the exe. #including does not increase your exe size.
That's basically exactly what #including does. There's a list of functions you can use in your code spanned out in several header files. You #include the files you want so that you can have access to all the functions contained in those files. The extra functions that you don't use in your app get dropped as soon as the compiler finishes parsing your file. They do not affect your exe's file size.
I'm a little unsure of what you mean by this. The only thing I'm aware of that VB automates that C doesn't is window creation... which takes a total of about 22 lines of code (which you can write once and copy/paste to other apps if you want). Well that and oddball things... like strings. If VB makes something super-easy that I'm unaware of lemme know.
What stupid limitations? Anything you can do in asm you can do in C. Although code will typically be faster if written in assembly. And you can even put chunks of asm inside your C code if you want. Assembly has to deal with pointers just like C does. In fact... lack of decent pointers is one of VB's fatal flaws. Proper use of pointers makes things SO much easier to code. Sure, coming from VB, pointers might seem a little strange... but that kind of is my point. Pointers are a simple, basic, fundamental, and manditory part of programming. The fact that VB doesn't make an effort to teach them is another reason why it's a poor language to start with (or even use).
Writing sloppy VB is no harder/less common that writing sloppy C. That's hardly a fault of the language. I've seen some pretty hellish VB in my time... but that's up to the programmer... not the language. And macros (your #define example thing) are an excellent part of the C language. Macros exist in most assemblers as well... and several other languages. If VB doesn't have them... it's just one more reason why it isn't up to par. (edited by Disch on 11-01-04 05:45 PM) |
|||
|
Dish Spiny Level: 38 Posts: 156/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 I would absolutly love to. Right off I can point you to this excellent tutorial which is actually how I learned. It covers making simple SDI windows (similar style to paint... or notepad). I'd also recommend you look up the CreateWindowEx() function on MSDN for a detailed explaination of all the params (specifically all the available window styles). If you want to work with Dialogs with pushbuttons and the like (or Forms, or whatever they're called)... I can write up something real quick that explains it. Just lemme know. As for your Dev-C++ problems... it might be adding debugging info to the build. Debug builds are usually bloated. You usually have to reconfig the compiler for a release build to optimize it. I have no experience with Dev-C++ so I can't really be specific, but I'm sure you could get those exe sizes down. As for which langauge is easier to learn/read... I'm still convinced C is the simplest... but neither of us are going to convince the other one... so let's just agree to disagree. And yeah... VB can do most of what C can (I'm still not quite sure about all.... can you do DLL builds in VB? Can you read from the commandline? Have direct access to the message pump?) I can understand the frustration with getting someone else's code to compile. And I must admit I'm pretty ignorant when it comes to this area -- my experience is pretty much solely with Visual Studio. From what I know... code (if written properly) will compile on any compiler (provided the needed headers/libraries are available), but getting the compiler and linker actually set up to complete the build can be funky. I think makefiles are made to take care of this, but I'm totally clueless about them. I really need to dive into some new compilers .I'm still not quite sure what you mean by being less limited with asm. But I'll concede that you are less limited (the lower level you go, the more control you have). |
|||
|
Dish Spiny Level: 38 Posts: 157/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| If you're doing opaque blits... you might be able to perform this with 2 seperate BitBlt calls.. first using WHITENESS and next using SRCINVERT (instead of a single call using SRCCOPY). I'm not sure how you'd go about it if you're doing transparent blits... at least... not without inverting the actual image (or making a copy and inverting the copy). |
|||
|
Dish Spiny Level: 38 Posts: 158/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| Yeah drawing on top won't matter... as long as the opaque image is drawn first. typical opaque blit: BitBlt( destDC, destX, destY, wd, ht, srcDC, srcX, srcY, SRCCOPY ); inverted opaque blit: BitBlt( destDC, destX, destY, wd, ht, srcDC, srcX, srcY, WHITENESS ); BitBlt( destDC, destX, destY, wd, ht, srcDC, srcX, srcY, SRCINVERT ); I haven't tested this but it seems like it would work. I'm unsure how it would look in VB, but I'm sure the params are the same (or similar). |
|||
|
Dish Spiny Level: 38 Posts: 159/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
Originally posted by Gavininvert picMain's colors. Well he said he wanted to just to an inverted blit, without changing the source image. The blit you gave looks like it would invert the source image (assuming picMain.hDC has the source image) I guess DSTINVERT would work too... but only after the image is copied with SRCCOPY. Almost any way you slice it.... it's going to take 2 blits... which 2 you use could be different though: SRCCOPY, then DSTINVERT WHITENESS, then SRCINVERT BLACKNESS, then MERGEPAINT or you could also load a solid white brush into the destination DC and blit with PATINVERT. The PATINVERT route would probably be the fastest since it only involves one blit. After that I would assume the WHITENESS/BLACKNESS routes would be a little faster than the remaining route... but that's just a guess. The MERGEPAINT and SRCAND combo doesn't look like it would work to me... it would make some interesting results, but it wouldn't be color inversion. For an explaination of how the color is found for each of these blit methods (think I have all these right, you may want to doublecheck though): SRCCOPY: dest = src DSTINVERT: dest = dest ^ 0xFFFFFFFF WHITENESS: dest = 0xFFFFFFFF SRCINVERT: dest = dest ^ src BLACKNESS: dest = 0 MERGEPAINT: dest = dest | (src ^ 0xFFFFFFFF) SRCAND: dest = dest & src To do an inverted blit, you ultimately want: dest = src ^ 0xFFFFFFFF I'm pretty sure the combos I mentioned will get you that result. MERGEPAINT and SRCAND will give you something funky though... like: dest = (dest | (src ^ 0xFFFFFFFF)) & src |
|||
|
Dish Spiny Level: 38 Posts: 160/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| I thought Mingw was an IDE for gcc/g++ bah... shows what I know about different compilers lol |
| 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 |
)
