 |
| 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: 221/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
Originally posted by Sonicandtails BWAHAHHAHAHHAHAHHHAHHA hhahahhahahhahha hahahhaha oh man.. I SOOooooo read that the wrong way at first XD |
|||
|
Dish Spiny Level: 38 Posts: 222/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| I second that motion. Having extra scrollbars is rediculous... they just make the page harder to navigate and your post harder to read. I don't even bother reading posts when I have to move from the main page scrollbar to the posters "special" scrollbar.. .I'll just skip their post (or read what's visible and skip the rest) A good layout should fit the post... the post should NOT have to be comprimised to fit the layout. The layout works for the post, not the other way around. Fixed layouts are bad. Scrollbar layouts are bad. |
|||
|
Dish Spiny Level: 38 Posts: 223/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| Well I got it somewhat ready: Source Binary The Binary is a demo exe which has a very shoddy UI slapped together for the purpose of testing the emu. There's still some bugs I haven't fully worked out (DQ4 doesn't like to run), and my timing isn't quite perfect (Rad Racer messes up sometimes), so I'll have to touch up / rewrite the PPU. But for the most part, it's good... it just needs a little more work. I figured it's better to get something out here so that anyone interested can actually work with something that is test-able. Be sure to read the readme(s) if you download. Lemme know if you're still interested / may be interested in the future ^^ HH (or anyone else): if you need this DLL-ifiied, I can do that for you... although I'm not sure if the function pointer thing I have going for the joypad input is very VB-friendly. I can do an alternate method if you need one. Feedback welcome/appreciated. |
|||
|
Dish Spiny Level: 38 Posts: 224/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| I use Visual Studio for pretty much everything. But MingW is a good compiler, gcc is good too. As for IDE... VS is good. There's an addon called Visual Assist which is great. But if you want something more lightweight (and free), TextPad might work. VS has a resource builder... and a good one at that. I don't know of any alternatives =/ although I'm sure there are some.
Strings are nothing but arrays. When you can think of a string as being synonymous with being an array... you can understand strings. Only difference is arrays tend to be fixed length (or have their length specified in a seperate var), wheras the end of a string is signaled with a null terminator. There are several string functions which aid in string manipulation: strcpy --- copy the contents of one string to another strcat --- append one string to the end of another strcmp --- compare two strings strcmpi --- ditto (case insensitive) strlen --- finds the length of a string sprintf -- string formatting! There's also search functions too, but I dont know them offhand.
You have it backwards. '&' is the Address-of operator... it gives you the address of (pointer to) the following var. '*' is the Indirection operator... it gives you what the following pointer is pointing to. '*' is also used when declaring pointers: int* foo; // makes an int pointer int var; // makes an int foo = &var; // set foo to point to var *foo = 5; // sets what foo is pointing to (in this case: var) to 5 (this is like saying "var = 5;") Another really cool concept with pointers is that an array without its brakets gives you a pointer... and brakets double as an indirection operator. For example: Saying *foo is exactly the same as saying foo[0]. foo[1] is the same as *(foo + 1). Etc. Since arrays without brakets are pointers, you don't need to use & when you want to get a pointer to an array: int* foo; int ar[5]; foo = ar; // foo will point to ar foo[3] = 0; //same as saying ar[3] = 0 Kudos on making the switch! There's really no reason at all to use VB ever... as you'll see when you get more comfortable with C. ;D (edited by Disch on 01-06-05 04:32 AM) (edited by Disch on 01-06-05 04:38 AM) |
|||
|
Dish Spiny Level: 38 Posts: 225/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 In VS, you #include the resource header file in any file that needs access to one or more resources... then use the resource ID's as needed. The .rc file also needs to be included in the build of the project. I'd imagine it's the same/similar for other compilers, but I really couldn't say. I completely lack experience when it comes to anything but VS  Many WINAPI functions take a resource ID in the form of a string.. but resources get IDs which are ints, which can make it kind of weird to use. For this, there's a MAKEINTRESOURCE macro which converts a resource ID to a resource string for these functions. For example... the DialogBox() function (which pops up a modal dialog) takes the resource string as the 2nd parameter. If your dialog id is, say, IDD_MAINDIALOG, it would look something like this: DialogBox( hInstance, MAKEINTRESOURCE( IDD_MAINDIALOG ), hParentWnd, MyDialogProcedure );
Yes. You could technically typecast the pointer to treat it as a normal int or whatever... but I'm just getting technical. Basically, you're right... a pointer does not hold a var, it just points to a var (or the start of an array of vars). And yeah... pointers are hard to get used to, but once you understand them they're soooooooooo great. @ Euclid: you're giving the right idea... but you're technically inaccurate, so I'm going to point out corrections (don't want to give HH misleading pointer info) Originally posted by Euclid foo will NOT point to NULL until you tell it to: int* foo = NULL; (or) int* foo = 0; uninitialized pointers are just like uninitialized vars. Their contents are undefined and they'll be filled with garbage RAM... effectively making foo point to random memory when unset.
No, blah is an array, so you don't need the '&' operator in this case. Remeber that an array without its brakets already is a pointer. char* foo = blah; // will set foo to point to blah.. no '&' needed. or: char* foo = &blah[0]; // this would work too... but your example wouldn't '&blah' will try to get a pointer to the pointer, which will probably make the compiler yell at you. Also note your different types... int is typically 4-byte... char is 1-byte. When working with pointers you typically want to point to a var of whatever type yout pointer is. When changing types you typically need to / should typecast: char blah[10]; int* foo = blah; this may generate compiler errors since blah is char and foo is an int pointer. To remedy this in my above exmples I changed foo to a char pointer. However if you want blah to be a char array and still want foo to be an int array... typecasting would be recommended (or even necessary depending on your compiler): char blah[10]; int* foo = (int*)blah; that will work without problems.
If foo is a char pointer. Yes. If foo was an int pointer, it would actually point to blah[4] (due to ints being 4 times the size of chars). When you add to a pointer, it adds by the element size... not by bytes. char blah[10]; int* foo = (int*)blah; char* bar = blah; -- at this point, both foo and bar point to blah foo += 1; bar += 4; -- at this point, both foo and bar point to blah[4]. (foo == bar) will come up true |
|||
|
Dish Spiny Level: 38 Posts: 226/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| The '~' key. I really wish you could reassign it you a joypad button. Fastforward is almost useless unless you can reach it from your playing hand(s). '~' is in the middle of nowhere... even when you're using the keyboard |
|||
|
Dish Spiny Level: 38 Posts: 227/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 Yeah you'll need a message handler =P. Typcially, when the dialog is to be closed, a WM_COMMAND message is send to the message handler, with BN_CLICKED as the high word of the wparam, and IDCANCEL as the low word (this will catch not only the escape button being pushed, but the 'X' in the corner, and also a press of a Cancel button if you have one on your dialog). To actually close the dialog, you need to call EndDialog(), which takes 2 params... 1st being the HWND of the dialog to close, and the second being its exit value (this is what DialogBox() will return with) so something like:
Most controls signal the main window through the WM_COMMAND message (like my example above). With WM_COMMAND, the high word of the wparam is the action being performed by the control (typically just BN_CLICKED for pushbuttons... but can be other things for other controls -- like for example, list boxes have a wide variety, like LBN_SELCHANGE, LBN_DBLCLK, and others). The low word of the wparam is the ID to the control (whatever ID you gave it in the resource editor... like IDC_BUTTON or whatever)... and if memory serves, the lparam is the HWND to the control. |
|||
|
Dish Spiny Level: 38 Posts: 228/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 Not really.. it's just weird that it all get channeled through the same function (instead of each message getting its own routine -- which is how I assume VB does it (MFC does something similar)). I guess it takes some getting used to.
Umm... you always have to use the resource ID... that's what it's there for. I must be misunderstand what you're saying 
For some things... yes. Like for stuff specific to the control, you'd have to send the control the appropriate message (like for setting a checkbox's check state, or adding strings to a listbox... stuff like that). But there's also a bunch of functions which will apply to almost any window (and remember that all controls are windows). So stuff like: SetWindowText() -- will change the display text (like the caption of a pushbutton, or the contents of an edit box) EnableWindow() - will enable/disable a control ShowWindow() - will show/hide a control |
|||
|
Dish Spiny Level: 38 Posts: 229/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
Originally posted by sloat Haha... I actually never knew about those before. They look like they're just macros though... like SetDlgItemText() just calls both GetDlgItem() and SetWindowText()
No you don't... they operate (more or less) the same way... only CreateDialog returns immedaitly rather than waiting for the dialog to close... and you exit with DestroyWindow (rather than EndDialog... like you mentioned). Other than that, it's driven the same way... you just supply a DLGPROC callback function when you call CreateDialog() and it feeds messages to it for you... no need to actually run your own pump. That's my experience anyway. I don't even see where you'd need to call IsDialogMessage or where you'd even put your pump. |
|||
|
Dish Spiny Level: 38 Posts: 230/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| As for your first problem... only thing I can think of, is resource.h isn't being saved before you compile. As for your memory allocation question: The C way is usually done with malloc() and free() functions. You #include <malloc.h>, and create your array with malloc like so: int* myarray; myarray = (int*)malloc( howmany * sizeof(int) ); 'howmany' would be however many ints you want to make memory for. If there isn't enough memory, malloc will return NULL, so you might want to check for that. Be sure to clean up whe you're done... or you'll have memory leaks in the program. You un-allocate the blocks with free(): free( myarray ); The C++ way is pretty much the same... but instead you use new[] and delete[]: int* myarray; myarray = new int[ howmany ]; delete[] myarray; (afaik, doesn't require any #includes, which I find to be strange, actually) Never mix malloc with delete.... or new with free. If you allocate something with malloc, use free. If you allocate something with new... use delete. The only real difference between the two is that new[] will call an object's Constructor (if it has one), and delete[] will call the object's destructor (if it has one) -- making it more useful for C++ classes and stuff like that. Whereas malloc/free will not call any constructors/destructors. |
|||
|
Dish Spiny Level: 38 Posts: 231/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
Originally posted by Ok Impala! I remember hearing that Seph was still working on it even after Vagla quit (this was before the leak though). I don't know if he still is working on it... though. |
|||
|
Dish Spiny Level: 38 Posts: 232/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
Originally posted by macbee I don't think it's prudent to call it "his" game... since the brunt of the actual work is (or at least was) being done by Seph3. Vagla is part of the project fo sho... but there would be no project without Seph. |
|||
|
Dish Spiny Level: 38 Posts: 233/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| .o files are object files. You still need to run the linker to make an executable. .cpp --> [compiler] --> .o --> [linker] --> .exe |
|||
|
Dish Spiny Level: 38 Posts: 234/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| 'true', 'false', 'TRUE', and 'FALSE' are like the stupidest keywords ever. Why the hell are 0 and 1 so inconvienient to type? =P I mean really... they're easier to type.. .and it's not like they're confusing. |
|||
|
Dish Spiny Level: 38 Posts: 235/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| I find OOP to me of a concept than an actual programming style. You can (and most if not all people do) program with somewhat of an OOP style in C and other procedural language (yes even you Para ;P). Even games on old consoles (NES) use OOP techniques and they're primarily written in assembly. So I find the whole concept of an "OOP Language" to be really, really stupid... since pretty much any language can do OOP. Whether you do classes with member functions in C++... or structs with accompanying functions in C... they do the same thing. Virtual functions in C++... or a function pointer inside the struct in C. Inheritance in C++... or putting a common "parent" struct inside another struct in C. Templates in C++.... or carefully placed #defines in C. There's nothing new that C++ adds to C... everything --- and I mean everything can be done in C... C++ just offers different ways of doing it (and since C++ also includes all of C... all the "new" methods are optional). I prefer to use OOP where appropriate... which is most of the time. However some things just don't need it... and languages that FORCE you to do things in an OOP style I find to be pretty silly (Java). Because of this... I consider myself to be a C/C++ hybrid coder. Object Oriented Programming is good... but it shouldn't be the only way. Rather it should be an idea you adapt into your coding style. Because let's face it... code that isn't at all object oriented blows unless it's a very... very small program. |
|||
|
Dish Spiny Level: 38 Posts: 236/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
Originally posted by Retro-Kasumi I guess you could say that. I mean the logic behind classes in C++ was definatly driven by OOP ideas. But like I said... there's nothing C++ can do that C can't (and vice versa)... it just uses different techniques for things. So when you say the language "supports" something... it doesn't support anything that C doesn't besides different syntax. Most of the C++ additions to C were just re-words of pre-existing C methods. The big paragraph in my post lays out the big ones: - C++'s virtual functions are nothing but function pointers - C++'s inheritance is nothing but putting the "parent" struct inside the "child" struct (for all practical purposes, classes and structs are identical in C++): class CChildClass : public CParentClass { //class stuff here }; that's the C++ version... the C version differs only slightly: typedef struct CChildClass { CParentClass parentobject; //rest of struct here }; They're both fundamentally exactly the same. But only one is branded as "OOP" by courses (even though they're both OOP -- I mean syntax aside, they're completely identical). OOP might be a little easier in C++... but it's not very hard at all to do in C. It's not a language thing at all... programming in a so called procedural language doesn't mean your code can't be OOP... and programming in a so called OOP language doesn't mean your code won't be procedural (like you said... you were doing procedural coding in Java). Hence my point of why calling X language an OOP language is stupid. It's not the language that makes it OOP... it's the style with which it's coded. |
|||
|
Dish Spiny Level: 38 Posts: 237/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 if creating a window in one thread and running the message pump in another thread is a good idea. I don't even see why you'd need a seperate thread at all (you could just check for messages periodically in your main thread... like say every frame or something). But that aside... if hVideoWindow is a valid window handle... PeekMessage WILL return true (unless that thread thing is a problem). Are you sure it's not returning true? I'm not exactly sure how printf() fits in here... since this isn't a console program (where are you expecting it to print to?) As for other potential problems... sometimes when vars are only used within a small area of code (like your StopWindowUpdateThread var in this example), the processor will keep the value in a register and not write it back to RAM. Basically... this will cause problems when you rely on your second thread to react to a change made to the var from your first thread. To avoid this... declare vars that MUST be "thread safe" as volatile: volatile int StopWindowUpdateThread; When you write to it in 1 thread... the second thread will be sure to pick up the changes on the next read. However this removes the occasional optimization which will make slower code... so only use volatile where needed (and try to keep the number of inter-thread variables to a minimum) But like I said... multithreading is not recommended unless necessary. - edit - bah... way to make my post useless XD (edited by Disch on 01-19-05 10:31 PM) |
|||
|
Dish Spiny Level: 38 Posts: 238/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 Not really. The time you spend processing windows messages is next to nothing. Besides... the CPU divies up processing time as needed for every running thread. You're still telling it to do the same amount of work.... making it divie up its attention to 2 seperate threads doesn't somehow make the processor run faster... if anything it makes it slower (more threads = more CPU split time). The basic idea is: Process all pending messages... Do a frame... and sleep if time allows (if you don't spend time sleeping, your program will gobble 100% of the CPU's time). For a demonstration: ---- while( runprogram ) { while( PeekMessage( wnd, &msg, 0,0, PM_REMOVE ) ) { TranslateMessage(&msg); DispatchMessage(&msg); } if( emulationpaused ) { Sleep(10); // if emulation isn't running for some reason, don't hog CPU time... sleep continue; // and go back to pump } DoAnEmulationFrame(); // check time here, if it's too early to do another emulation frame, Sleep for a while } ---- that runs suprisingly fast... hardly any CPU time will be spent on the PeekMessage loop. And if your time checking code is good... it can be smooth. The Demo NES Emu I made a while back does something like this. You can check the winmain cpp file in the source of said emu (or whatever the file is named) for a demonstration. That emu is very quick on my machine (typically no more than 0-1% CPU time) Running multiple threads won't speed anything up... they may actually slow things down a bit. Not to mention they severly complicate things and cause lots of weird quirks (like your prior window problem). |
|||
|
Dish Spiny Level: 38 Posts: 239/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| I'm sure there are. C/C++ have evolved a lot over the years... some older C code won't even compile on modern compilers. Get a book that's up to date. |
|||
|
Dish Spiny Level: 38 Posts: 240/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 Fixed. Hahaha... I'm just being a wiseass. But really... GB has too shitty of a res... its games are really... really hindered because of it. I mean Mario takes up 1/10th of the screen in that game.... the screen is so small it has to scroll up when you do a normal short jump.
This concept if fundamentally flawed. A universal music edtior is no more possible than a universal level editor. Different music routines use different spaces in RAM... different -amounts- of RAM... different sound channels... some take more space... some take less. On top of that... there's no way for a program to magically find music data... since music data can look like anything. That's like wanting it to find level data -- it just can't be done through automation (or at least... not without full emulation and one hell of a logic sequence -- and even then it'd be iffy). And even if you somehow manage to make a program find and convert the music data to a common format -- you'd essentially have to reprogram the music engine in the ROM to play the new format. Again... finding the music playback code and rewriting it is not a job best suited for a machine. Add space issues, sound effect conflicts, and a slew of other problems and you might see what I'm talking about. (edited by Disch on 01-21-05 07:39 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 |
)
(Of course given that I didn't provide any message handler, I'm surprised it works at all. 