 |
| 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: 421/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| It completely depends on the person. If you have prior programming experience, you will pick it up pretty quick. If it's your first language it will take longer since you sort of have to learn the whole concept of programming. I really couldn't give you an accurate answer |
|||
|
Dish Spiny Level: 38 Posts: 422/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
reread my post  The emulator is called "It might be NES". You can get it at that site I linked to along with information. |
|||
|
Dish Spiny Level: 38 Posts: 423/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
Originally posted by ||bass I suggested he start with C then move to C++, since C is considerably simpler, and everything you learn in C can be directly applied to C++. And yes -- C++ includes all of C, so C++ is just C with extra stuff . I agree that it's more geared towards doing OOP, but all C++ really is is glorified C. Pretty much everything extra is offers can be accomplished just as easily in C except for maybe templates (although with C the code will be more verbose). Classes, inheritance, virtual functions, all that stuff can be easily mimiced in C with clever struct and function pointer usage.It's not the language that makes your code OOP -- it's how you code. You can just as easily code object oriented C code as you can object oriented C++ -- and you can just as easily code structured C++ as you can structured C. I agree about avoiding DirectX. Personally I'm a big fan of the SDL + OpenGL combo. EDIT: I don't mean to sound like I'm knocking C++ -- I'm not. I agree he should learn C++ -- I'm just saying C might be easier to start with. EDIT again: even templates could be mimiced in C with clever #define usage (edited by Disch on 06-08-05 10:04 AM) (edited by Disch on 06-08-05 11:32 AM) (edited by Disch on 06-08-05 11:36 AM) |
|||
|
Dish Spiny Level: 38 Posts: 424/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| I guess the thing I'm concerned with is C++ generally throws a bunch of abstract stuff from the get-go. cout is a good example -- it's usually one of the first things taught when learning C++... but how it works is almost like magic (its syntax doesn't make any sense at all) until you learn about classes, operator overloading, references, and other (fairly abstract) concepts. There's nothing abstract like that in C. The closet thing to it in C is the '...' variable param count option like in printf. Because of that, all the syntax is consistent and easy to understand right away. Very little is presented in a "don't worry how this works, we'll get to it later" manner -- which can make things a lot easier to pick up.
Picking up any programming language for the very first time involves a lot of conceptual stuff... that's actually most of it. When you already have an understanding of conceptual stuff -- yeah, C++ is pretty easy to pick up. However, when you're learning your first language, you not only have to learn language specific stuff, but you also have to learn programming concepts. When you're learning both at once, it's best not to be bombarded by two much of either. C is more simplistic, so there's less to know going in -- so it'll be less intimidating. Once you get the concept and syntax basics, moving to C++ is seamless. You don't have to change anything (it's not 'stopping and changing gears' as you put it... C++ IS C, just with more things). So all you have to do to make the transition is just start reading docs that cover C++ specific stuff like classes. You don't have to drop anything you learned -- you don't have to stop learning what you're learning -- everything you learned in C is applicable in C++. I'm not saying he should become an accomplished programmer with C -- I'm just saying he might want to use it when starting out because it's simpler (and it is!) I agree that once he gets conceptual and fundamental stuff down he should make the switch. EDIT: anyway -- I dont' really disagree with you. Truth is C++ isn't a bad thing to start with either. I just thought starting with C would ease the blow a little bit -- but then you all came in with "omfg that's a horrible idea!" when I honestly can't see a single downside . But whatever. I'm not in a bickering mode (omg hell froze over!) so this will be my last post on this subject.(edited by Disch on 06-08-05 05:04 PM) (edited by Disch on 06-08-05 05:11 PM) |
|||
|
Dish Spiny Level: 38 Posts: 425/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| Final Fantasy Legend are actually SaGa games if you want to get technical. They were just renamed "Final Fantasy Legend" when they came stateside. They're not like the rest of the FF games (since they're from a different series entirely) Likewise, Final Fantasy Adventure isn't even an RPG. It's more like an adventure game (more like Zelda). Final Fantasy Adventure was actually "Seiken Densetsu". You may know Seiken Densetsu 2 as "Secret of Mana" -- which was the sequel. SD2 was a very good game. SD3 was even better (for SNES) -- and is highly recommended. I wish I could recommend SD1/FFAdventure.. .but I just freaking hate Gameboy. Final Fantasy Tactics (both PSX game and Advance game -- although the PSX game was MUCH MUCH MUCH MUCH better) flow in a completely different vein from the rest of the series. As the name suggests they're more like tactical battle games than RPGs. FFT for the PSX is quite possibly one of the best PSX games in existence -- with probably the best soundtrack I've ever heard in my life. FFTA was a severe disappointment and I wouldn't even bother with it. Scatterheart left out Final Fantasy Origins for PSX (which had remakes of FF1 and FF2) -- although I still recommend the NES versions -- or at least the NES version of FF1. FF1 had a port to the MSX as well. Plus FF1, 2, and 4 has versions for the WSC (not very popular handheld system never released stateside) To avoid possible confusion: Final Fantasy 4 had both an easy and hard version -- Hard version is recommended, as it has more items, more character abilities, etc. Easy version is very easy. Also, when released in the states it was renamed "Final Fantasy 2" -- so the SNES FF2 and the NES FF2 are different. The SNES FF2 is actually FF4 (closer to the easy version). FF4j hard-type for SNES is recommended over all other versions. Final Fantasy 6 was changed to "Final Fantasy 3" when released stateside -- so the SNES FF3 is really FF6. I don't believe the J and US versions are much different. |
|||
|
Dish Spiny Level: 38 Posts: 426/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
Originally posted by Aeclml DId you even look at the page? =P Yah those are emus for use on the PSX As far as a SNES emu for PSX is concerned, it's not gonna happen. The SNES emu for the Dreamcast is barely able to hold a decent speed -- and the DC is a FAR more powerful system than the PSX. |
|||
|
Dish Spiny Level: 38 Posts: 427/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| Couldn't you just remove those graphics from the pattern tables? Why is that not a 'real' solution? The simplest solutions are often the best. |
|||
|
Dish Spiny Level: 38 Posts: 428/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| Quite frankly -- I hate making editors. The 'making editor' portions of my game projects seem to always kill all my motivation, and eventually the project. I'm actually taking a break from my main game project (which, suprise suprise, is in the editor developing phase) to do a simpler game project. I'm keeping it very simplistic -- only thing I need an editor for is maps. SO! I'd like to request aid in the form of a map editor! Any language will do (even VB!) The map format is painfully simple: - Only one layer -- no multi-layered maps - No tile animaion - Tiles are 16x16 pixels, completely opaque -- no transparencies - Tile ID is 8-bits -- only 256 tiles can be on a map - Maps can have configurable width/height (no less than 20x15 tiles -- limit within reason -- I doubt it will get very large though) - the "tileset" is nothing more than a 256x256 bitmap -- each 16x16 pixel block is a tile ID number. There are no further properties that need to be edited for the tiles. - Map compressed with a simple RLE method. I can provide the compression/decompression code if you really want (assuming C/C++) -- or I can explain it if you want to do it yourself (it's very simple) - Misc objects will be placed on map -- each object only needs 3 things: ID number, X coord, Y coord. No further properties need to be edited for those objects. - Number of objects on the map needs to be configurable - The player doesn't count as an object -- so the player also has a starting point in the map (just X,Y position) - Graphics for each object don't have to be in the editor. If you want you can just put a star, or some other indicator at the location of each object. That's all. I'm not picky about how the editor works as long as it works. I don't even care what it's written in as long as it's not a pain to use. This doesn't have to be a commercial grade editor -- it doesn't even have to be user friendly. Further details and the actual detailed map file format will be posted on request if anyone is interested in taking up this project. There is no reward or anything for making the editor. All you get is the satisfaction of knowing you contributed to a moderately entertaining game, and my eternal gratitude. Due to this project being very simple, it has a full head of steam -- contrary to some of my other projects I see this one actually being completed in the semi-near future -- and not just fizzling out. So you can be pretty confident that your editor will be put to good use and won't be a complete waste of your time -- however I am moving halfway across the country soon, so there might be a decent sized pause in my activity in the near future. The editor may or may not be publically available -- it's completely your call. The game will be open sourced on completion and will be free. I'm leaning towards mashing together all the individual map files into one big file for all the maps for the final release of the game -- but I'd prefer individual files (1 file = 1 map) for the developing phase. It's easier on the editor and it's easier for making/editing the levels -- so it's possible your editor may not be operable on the final release of the game unless you tweak it. I have a small demo up and running, but I'd rather not show it here due to it being less than impressive. There's no animation (outside of the player moving and the screen scrolling), and no objects on the map -- and no sound -- however I have the player moving about the map and all the wall collision and crap working perfectly (which actually is the hardest part -- the rest will flow like wine for me). If you're interested in making the editor but are unsure and seeing the demo may sway you -- I can slip you a copy. I'm not interested in adding anything to the map other than what I specified. If you have further ideas on the game, that's great, but I likely won't be interested. I'm restraining myself on this project and keeping things simple -- further ideas just complicate things, and once you add one thing you think of another thing and then you have all these ideas and I have to redo all the code I did. If you'd only be interested in making the editor if you have some say-so of how the maps operated -- then you probably aren't interested. To be frank... it's "my way or no way" when it comes to how this particular game works. At least for now -- in the future I might be open to suggestions (but then again I may not). That's it! If you have further questions, or have any interest at all -- please reply. I'd really love to avoid making an editor if possible (I hate making editors). Any help appreciated! Thank you for your time. EDIT ---- The file format: Tileset ID will load a file "ts_xx.bmp" where 'xx' is the hex value of the ID. So an ID of $05 will load "ts_05.bmp" for its tile graphics. ANOTHER EDIT!!!!! Just realized I'll need additional info for some of the objects I have in mind -- so I added a 16-bit var to the objects section. (edited by Disch on 06-10-05 12:37 PM) (edited by Disch on 06-10-05 01:08 PM) (edited by Disch on 06-10-05 01:11 PM) (edited by Disch on 06-10-05 02:36 PM) (edited by Disch on 06-11-05 11:17 AM) |
|||
|
Dish Spiny Level: 38 Posts: 429/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| http://www.geocities.com/disch_/TestLevel.zip The test level, the tileset it uses, and a png with how the result should look (with a cute little mouse to indicate where the player starts) Nothing in the map is compressed since I made it in a hex editor -- so hopefully an editor would shrink the file after loading and saving. Also --- after I posted this, jman on IRC said he was interested as well -- I believe he already started working on it (he said he'd have something by the end of today). So I might not need you. I'll meet up with him as soon as I can and make sure he's really doing something -- then I'll get back to ya. Thanks ^^ |
|||
|
Dish Spiny Level: 38 Posts: 430/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| Object Orientation is a programming style -- not a language feature. You can do OOP in pretty much any language (including C). The reason C++ is called an "OOP language" is because it was designed with OOP in mind and makes some things easier to work with in that respect -- but I really hate calling it that because ANY language can be an OOP language. Hell I can write object oriented code in 6502. | |||
|
Dish Spiny Level: 38 Posts: 431/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
Originally posted by Ramsus C example of OO function calls: C++ example of OO function calls: C example of inheritance: C++ example of inheritance: C example of virtual functions (aka function pointers) C++ example of virtual functions If you call that "ugly as hell" -- then you and I have vastly different opinions of what ugly code is. The ONLY things C++ really changes in this area are: 1) Automation associated with the this pointer (so when in member functions you can just access them without any prefix -- whereas in C you'll have to do obj->varname for every member var). 2) Same as above, but includes the this pointer to include any and all parent classes. C++ can just do 'varname' rather than 'obj->parent.varname'. Exception of course when both the parent and child have a var with the same name -- in which case C++ has to do 'PARENT::varname' if it wants the parent version. 3) Automatically calling ctor/dtor member functions upon object creation/destruction 4) Automatically filling in virtual function pointers upon object creation And yes -- I'll agree -- all those things make OOP easier and more convienient (which I actually mentioned in my previous post). However they are not necessary for OO design. Labelling C as a "non-OOP language" or some variant is completely misleading -- because it Can be Object Oriented. Almost any language can. It all depends on how you use the language. Some languages may have features to make it easier (and in fact -- one could very easily argue that C's structs are such a feature), but that doesn't the languages which lack those features are not as capable. The features of the language do not even dictate how you code. It's very easy to make non-OO code in both C++ and Java. Because it's like I said: OOP is a programming style -- it's not a language feature.
Honestly, I fail to see where the line is drawn which determines which languages are OOP and which are not. As far as I can tell, if a language uses the 'class' keyword it's OOP, and if it doesn't it's not . That's really the only sense I can make out of the current labels.(edited by Disch on 06-12-05 08:38 AM) |
|||
|
Dish Spiny Level: 38 Posts: 432/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| I'm at a loss for a reply. I don't necessarily disagree with anything you just said -- but it doesn't seem like you disagreed with anything I said either. Perhaps we're just arguing different points? I don't like labelling languages as Object Oriented or Procedural -- since it's really up to the coder to determine one or the other -- the language used is irrelevant. That's all I'm saying. Yes I agree OOP is easier on C++. I never said it wasn't (in fact I said it was in every reply). I don't agree that C++ can be only used for OOP -- or that C cannot be used for OOP (which is what calling a language OOP or not implies). C++ was designed with more OOP concepts in mind -- however considering everything C++ does can be easily mimiced in C, it's not really fair to say C wasn't designed with OOP concepts in mind -- because it was kinda. Perhaps it doesn't rely as heavily on OOP as C++ -- but where do you draw the line? |
|||
|
Dish Spiny Level: 38 Posts: 433/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| I just tried the download link and it worked. | |||
|
Dish Spiny Level: 38 Posts: 434/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| the system.cnf file looks like it's set up to make the exe run from CD rom perhaps the exe and cnf files are burnt to disk along with ROMs -- and that's how you run the emu. The exe might not be a windows app. |
|||
|
Dish Spiny Level: 38 Posts: 435/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| Agreed. If you're not really that interested in programming, and just want a quick way to pump out cross platform proggies, then Java is your friend. | |||
|
Dish Spiny Level: 38 Posts: 436/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 Any reason why you've chosen the yukky PAL version over either of the more common NTSC versions? "Mario Bros.(JU) [!]" or "Mario Bros. (JU)". Or is Mario Bros. Classic different from Mario Bros? On second thought... is there even a PAL version? |
|||
|
Dish Spiny Level: 38 Posts: 437/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
What ramsus said. For loops are exactly the same as while loops, except they have an opening and iteration statement. The only time this makes any real significance is when you use 'continue' to restart the loop -- in which case the while loops starts over, whereas the for loop runs its iteration then starts over. Example: |
|||
|
Dish Spiny Level: 38 Posts: 438/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| You might be on the right track with that. do your 32768 / x and get the result and remainder. Multiply them both by 4, then divide the remainder by x again, add that result to your previous result and the new remainder is your remainder. This means two divisions, which would be pretty slow -- you might be able to speed this up by having a chopped down version of your division routine (the result of the second division can't be greater than 3). Example: 131072 / 1998 = 65 remainder 1202 32768 / 1998 = 16 remainder 800 16*4 = 64 800*4 = 3200 3200 / 1998 = 1 remainder 1202 64 + 1 = 65, with a remainder of 1202 |
|||
|
Dish Spiny Level: 38 Posts: 439/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| Using the processor as-is without emulating it wouldn't work for the simple reason that you wouldn't catch register writes. For example, to output graphics on the NES, you typically write to $2006 twice, then to $2007 several times so send data to the PPU. On the SNES, $2006 and $2007 are not PPU registers but something else entirely (RAM perhaps? not familiar with SNES). So an NES game will be writing to these areas, but unless your emulator is watching what the NES game is doing, your emu will just be writing junk values to RAM instead of taking those writes and giving them to your PPU emulation. Among other things -- like cycle timing. NES games do lots of timing tricks for split screen effects and other things. For example a game might set scroll values to something at the start of a frame... then wait for, say, 2000 CPU cycles, then change the scroll values. On the NES, these 2000 CPU cycles translate to about 18 scanlines, so were a game to do this, it would cause a split screen effect (top portion of the screen scrolling independently of the bottom half). Even the simplest of NES games use techniques like this (see Balloon Fight, Excitebike). So your SNES emu will have tally up a running total of cycles as emulation progresses. So yeah... even though the processors are the same or similar... you still have to emulate the CPU instruction-by-instruction (at least in this case). However, I'm not really familiar with the SNES and what it can do, so I might be off base on a few points (however I still find it unlikely). There already has been a halfway decent NSF player for the SNES (however the triangle and noise are a little sketchy and the DMC is completely missing). But I find a full emulator somewhat out of the question. (Not to mention completely pointless) |
|||
|
Dish Spiny Level: 38 Posts: 440/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| erm... well the "some kind of converter" you're talking about is called an emulator. That's exactly what they do. However despite the similarities between NES/SNES processors (and PPUs?) it would still take a great deal of work to get an NES game running on the SNES. I'm willing to bet it's more than the SNES can handle (or at least handle at any reasonable speed without leaving out sound emulation or other areas). Here's what I'm saying: The SNES can't just run the NES game's code (well I guess it could, but it wouldn't do anything) -- The fact that they have similar processors means absolutly nothing. The SNES emu would have to examine each and every executed instruction and do things like write/read register checks, and cycle count totalling. You're talking an extra 15 or so instructions for every single instruction the NES game executes -- and that's JUST for CPU emulation -- you still have PPU, APU, mapper emulation and timing issues to worry about besides that. (edited by Disch on 07-16-05 02:59 PM) (edited by Disch on 07-16-05 03:10 PM) (edited by Disch on 07-16-05 03:12 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 |
