 |
| 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 Disch |
| User | Post | ||
Disch Micro-Goomba Level: 4 Posts: 1/16 EXP: 226 For next: 53 Since: 10-21-05 Since last post: 12 hours Last activity: 1 day |
| ||
| [15:22:29] <Disch> goddamn [15:22:36] <Disch> I know I shouldn't [15:22:38] <Disch> but fucking hell [15:22:47] <Disch> http://board.acmlm.org/thread.php?id=19777 [15:22:56] <Disch> okay [15:22:58] <Disch> what's worse [15:23:23] <Disch> the fact that this guy made a hack where all he does is take away image detail ("omfg make it transparent!") [15:23:36] <Disch> or the fact that everyone is kissing his ass like it's some kind of great/interesting/new idea [15:23:43] <Disch> I swear man [15:24:00] <Disch> if that's what ROM hacking is reduced to these days... where something like that is a hack to "look forward to" [15:24:01] <Disch> then goddamn [15:24:31] <Disch> there have been hacks like this since the NESticle days [15:24:33] <Disch> so it's not a new idea [15:24:41] <Disch> in fact... there probalby already was a hack exactly like this [15:24:44] <Xin> hahahahaha [15:24:52] <Xin> that guy made like 5 of those threads [15:24:55] <Disch> I KNOW [15:25:01] <Disch> AND THEY'RE ALL THE FUCKING SAME [15:25:09] <Disch> He made an opaque mario or some shit [15:25:17] <Disch> and all he did was make everything one color [15:25:19] <Disch> WHAT THE FUCK [15:27:06] <Disch> I didn't see any critism in the posts I saw [15:27:21] <Disch> they were all "awesome and interesting idea! Transparent, but doesn't look like crap" [15:27:57] <Disch> here's what I don't get [15:28:15] <Disch> Rockman did a hack where the oil was just a black square and he got his ass TORE UP for it [15:28:22] <Disch> this guy did an entire hack WHERE EVERYTHING IS LIKE THAT [15:28:27] <Disch> and people are saying "wow, neat!" [15:28:35] <Disch> Am I in bizarro world or something? [15:28:39] <Disch> did everyone go insane?! [15:28:46] <Disch> What the fuck happened? [15:29:09] <Disch> I FEEL LIKE I'M TAKING CRAZY PILLS [15:32:51] <Disch> I think everyone's afraid of being too mean ever since that "trouble with rom hacking" thread bullshit where the dude talks about being too mean to newcomers If you're reading this shane (and I hope you are)... I wish I didn't have to be so blunt... but I fear that tip-toeing around my point for the sake of being polite wouldn't counteract all the underserved positive feedback you've received... and that my comments would crumble beneath "that guy doesn't know what he's talking about, all these other people liked my hack". The bottom line is... the 3 hacks I'm talking about (transparent mario, transparent megaman, solid mario) consist of nothing. They took neither imagination, creativity, artistic skill, dedication, hard work, nor any other value that gives the hack a single redeeming quality. I'm not sorry to say that your hacks are the epitome of complete shit. A braindead 4-year old could've made those hacks.... I mean all you had to do for them was color inside the lines. At least Big Penis mario and Afro Mario, and all those other shit hacks took some kind of drawing talent (even if the graphics were poor, they were at least drawn by the person making the hack). And as such they took greater effort and were more worthwhile than what you've provided us so far. I don't mean to dissuade you from hacking. I'm just saying you should try to actually DO SOMETHING in your future hacks. To everyone else: come on. You're so scared of being rude that you're completely numbed and have no objective sense anymore. When hacks like these get two pages of positive feedback and not the SLIGHTEST BIT of critisism, it sort of cheapens the quality of positive feedback. I mean what does it mean when you say "good work" to someone who busts their ass to make a superb hack if you're just going to turn around and say "good work" to any shmoe that spends 5 minutes in Tile Layer intentially removing graphic detail. Use your heads. I'm particularly disappointed with you, DD. But I'll bring that up the next time I see you on IRC. (edited by Disch on 10-20-05 05:01 PM) |
|||
|
Disch Micro-Goomba Level: 4 Posts: 2/16 EXP: 226 For next: 53 Since: 10-21-05 Since last post: 12 hours Last activity: 1 day |
| ||
| Now that I've started this thread, it seems several people have suddenly come forward and said things in the hacks' threads. I don't know if that's coincidence.... or if you guys just need someone to take that step before you're willing to say something... or what =P But if you guys would have said something from the start, I wouldnt've had to make this big old fat mean post.  Since after all, my beef wasn't with the hacks so much as it was how they were being received.... I mean there have always been bad hacks... that's hardly something to start a ruckus over.One more thing....
Come on.... no you didn't. I mean really, if that kind of hack peaks your interest then you must have like zero standards. I mean if you wouldn't call that hack bad... what hack would you call bad? EDIT I guess BMF was the first to say something (at least that I saw) in that solid SMB thread -- I just must have missed it the first time around. (edited by Disch on 10-20-05 07:30 PM) (edited by Disch on 10-20-05 07:36 PM) |
|||
|
Disch Micro-Goomba Level: 4 Posts: 3/16 EXP: 226 For next: 53 Since: 10-21-05 Since last post: 12 hours Last activity: 1 day |
| ||
Originally posted by flamepanther You're basing it on a bad dump of SMB. Some bad dumps of SMB expect RAM to be flushed with 00 at startup, when in fact all but 4 bytes are flushed with FF. The bad dump reads and uses a byte before ever writing to it -- expecting it to be be 00 the first time (presumably to start at level 0 [1-1]) but instead it gets level FF [ -1]. This is a semi-recent discovery... so older emus will play the bad dump fine.. whereas more modern emus will choke. If possible, move your hack so that it's based on a proper SMB dump and not one of the million bad dumps floating around. |
|||
|
Disch Micro-Goomba Level: 4 Posts: 4/16 EXP: 226 For next: 53 Since: 10-21-05 Since last post: 12 hours Last activity: 1 day |
| ||
Originally posted by insectduel Do emus even support those iNES trainers any more? Those were just used back in the NESticle days because goons needed more PRG space for their crappy FFE mapper hacks. Nowadays, you really shouldn't use the 512 byte iNES trainer. I'd be suprised if modern emus even support it... since it conflicts with other areas (like cartridge WRAM/SRAM). Afaik, most [good] emus just skip over it and ignore it if it exists. If you need more PRG space -- do the job right and free some up. The last thing the world needs is more bad/broken NES ROMs. Especially of the SMB variety. There's already enough bad dumps floating around as it is. Not to mention I don't see how adding a trainer has ANYTHING to do with changing the CHR (graphics). You could just as easily change the graphics without adding the trainer. (edited by Disch on 10-29-05 03:25 PM) (edited by Disch on 10-29-05 03:31 PM) |
|||
|
Disch Micro-Goomba Level: 4 Posts: 5/16 EXP: 226 For next: 53 Since: 10-21-05 Since last post: 12 hours Last activity: 1 day |
| ||
Originally posted by insectduel As I previously stated --- there are lots of bad dumps of SMB floating around. The real, actual, true, proper SMB dump is exactly 40k (32k PRG + 8k CHR) + 16 bytes for the iNES header. That's 40976 ($A010) bytes. Any SMB iNES ROM larger/smaller than that is bad. ANY Rom can have a trainer on it... my point was that the trainer is probably ignored by emulators -- so adding a trainer does absolutely nothing aside from waste 512 bytes... and contaminate the ROM pool. Instead of learning how to add trainers... you should be learning how to remove them ;P And like I said -- the trainer has absolutly nothing to do with graphics. |
|||
|
Disch Micro-Goomba Level: 4 Posts: 6/16 EXP: 226 For next: 53 Since: 10-21-05 Since last post: 12 hours Last activity: 1 day |
| ||
Originally posted by hamtaro126 Grah... NSFs are not interchangable between ROMs!! The nsf_in_rom inserter you linked to before was merely a code base to turn .nsf files into executable .nes files. It does not insert NSFs into SMB1 (I don't know where you got that idea)... nor does it insert NSFs into any ROM. It converts an NSF to its own ROM. Music code requires it's own PRG space and RAM space. The only way music will be interchangable between ROMs is if the music code in both games exists in the same area, and uses the same RAM*. This will be the case for some games, since many games by the same company recycle the same music engine, so you can drag and drop music data from one game to the other (like some Capcom games -- I think bbit was working on an editor for that back in the day, wonder what happened with it). * Disclaimer: it is of course possible to manually move the code and make it use the free RAM space... so it's possible to put an NSF in any game -- the same way it's possible to put one game's level data in another (ie: through a shit-ton of work) Game source (and commented at that) is always a great thing though =D. This thread is indeed good news -- I just felt it necessary to mention that the music thing doesn't really have anything to do with the SMB thing. |
|||
|
Disch Micro-Goomba Level: 4 Posts: 7/16 EXP: 226 For next: 53 Since: 10-21-05 Since last post: 12 hours Last activity: 1 day |
| ||
Originally posted by creaothceann Neither heap nor stack memory is ever initialized with 0. Uninitialized variables ALWAYS have undefined contents in C/C++. Never assume the state of anything -- always write before you read. But yeah... I would agree that HH should do a memset(&b,0,sizeof(BITMAPFILE)); before filling his struct. Not only does it avoid having to set several vars to zero, but it also makes sure you don't MISS setting any vars to zero.
As HH pointed out, dot (.) is different from the arrow (->) in that the arrow performs indirection. As for your most recent problem, HH -- the FILE doesn't need to be padded to 32-bits... but the BITS do. A scanline may end on an odd offset in the file... just so long as the offset from the start of the bit data lands on the 4-byte boundary. The pitch of the bit data can be determined with the following formula (for windows bitmaps, at least): So at the end of the scanline, after outputting N bytes of pixel data -- merely output (pitch - N) bytes of padding. ftell(), your position in the file is irrelevent. (edited by Disch on 10-30-05 11:40 AM) |
|||
|
Disch Micro-Goomba Level: 4 Posts: 8/16 EXP: 226 For next: 53 Since: 10-21-05 Since last post: 12 hours Last activity: 1 day |
| ||
| Kind of off the subject... but since Grond is here, I figured I'd take this opportunity. Grond: in your next hack.. please don't break the header The last few bytes are reserved -- they're not advertising space. ;PBut yeah... FF++ rocks. |
|||
|
Disch Micro-Goomba Level: 4 Posts: 9/16 EXP: 226 For next: 53 Since: 10-21-05 Since last post: 12 hours Last activity: 1 day |
| ||
Originally posted by HyperHacker use the pitch, my son! The pitch! The width should never be used in this manner -- that's what the pitch is for. data -= image->pitch * 2; or whatever the SDL pitch var name is (possibly 'p'?) (edited by Disch on 10-30-05 02:02 PM) |
|||
|
Disch Micro-Goomba Level: 4 Posts: 10/16 EXP: 226 For next: 53 Since: 10-21-05 Since last post: 12 hours Last activity: 1 day |
| ||
| There was a discussion on this on nesdev a while ago, and ideas were thrown around quite well. And in fact blargg made a working rewind feature in his emu (though it's an unreleased personal emu). Complete with matrix-style slowdown before rewinding (and when you let go of rewind, it slows down, the plays normal speed), and backwards music, no jerky missed frames (a la ZSNES's rewind... at least the last time I used it) -- the whole 9 yards. I've been wanting to put one in Schpune, but I hate working on that end of development. If I do cave and make my own front for Schpune down the road (not very likely -- at least not in the near future) -- I definately will make a rewind feature. The concept isn't too difficult -- and it's very clever. And yes it does use a substantial amount of RAM. But not enough for it to be a big issue (who DOESN'T have an assload of RAM these days?) - Always be recording a movie. - Savestate at key times every X frames - Keep snapshots of the last Y frames - Keep produced audio of last Y frames stored in a buffer More Savestates = more RAM, but eased CPU usage on rewind. More snapshots = MUCH more RAM, but MUCH easier on CPU usage. Some snapshots are definatly needed though. Old movie data, savestates, snapshots, audio can be deleted once it gets too "outdated". For example, if you want to allow rewinding up to 5 minutes -- then you can trash savestates and movie data after they're 5 minutes old. Snapshots and audio can be deleted much sooner -- like after 1 or 2 seconds. When the user rewinds, you feed him old snapshots and old audio (played in reverse), while loading a state and running the movie code to produce more snapshots/audio. Most of this stuff could be easily user configurable as well -- like the length of time they want to be able to rewind (5 mins is a hell of a lot), how much snapshots/audio to keep buffered... that kind of thing. |
|||
|
Disch Micro-Goomba Level: 4 Posts: 11/16 EXP: 226 For next: 53 Since: 10-21-05 Since last post: 12 hours Last activity: 1 day |
| ||
Originally posted by infidelity The trick with that is, the game is loading the song ID number into A and then jumping to the "Music Init" routine to load a song. This is common practice in many games. Fortunately, many people already filtered through all the code and stuff required to find the address of that Init routine -- to rip NSFs! So if you want to know the Init routine of the game, there's a good chance you can just pick up the NSF, and look at offset 0x0000A and 0x0000B (the Init address in the NSF header) and use that value. It won't work all the time, but it's worth a shot. |
|||
|
Disch Micro-Goomba Level: 4 Posts: 12/16 EXP: 226 For next: 53 Since: 10-21-05 Since last post: 12 hours Last activity: 1 day |
| ||
| I think Xodnizel's (FCEU author) latest emu may have a rewind feature like blargg's. The emu used to be called Nintencer, but then he changed the name and for the life of me I can't remember the new name. You might want to look around for that one. Other than that emu -- I don't think any other one rewinds. |
|||
|
Disch Micro-Goomba Level: 4 Posts: 13/16 EXP: 226 For next: 53 Since: 10-21-05 Since last post: 12 hours Last activity: 1 day |
| ||
| Surface pitch is the number of bytes between pixel rows on a surface. So if an 8-bit image has a width of 256 and a pitch of 256 -- then there's no padding. If the pitch is 260 then there's 4 bytes of padding. (Though "padding" is a misleading word... as this space may be used by other surfaces or for other video memory and should not be zeroed/touched by your program!) Nearly all surfaces in hardware memory (and even most/many in software memory) will have some padding -- ie the pitch will NOT match the width... and you much never use the width when calculating the pitch... the two are unrelated. An image with a width of 2 pixels might have a pitch of 512 bytes... you never know (though that paticular example is pretty unlikely). SDL will fill the 'pitch' member of the SDL_Surface struct with an appropriate value, provided the SDL_Surface is a real surface (so unless you tried to make one without SDL_CreateSurface or something, you should be fine). You also may have to LOCK the surface for the pitch to be valid (though I'm not 100% sure with SDL) -- but you really should already have it locked if you're accessing the pixel data. If you're reading pixels from an unlocked surface, shame on you ;P The only things I can think of, is either your pitch value is bad somehow (not likely), or you're starting at the wrong point and coming out before the start of the buffer (very likely). I see that you're starting from the bottom of the image and working up... when you calculate to find the last scanline of the image... are you still using the width? I'm willing to bet you are ;D If you want to retrieve the last scanline of the image, use the following formula to get the offset (in bytes) from the start of the buffer: offset = (image_height - 1) * image_pitch; The width should NOT be used in any calculation of this sort... ever. The pitch... my son. The pitch. EDIT (again) I actually just realized that the formula I gave you was wrong. Whoops! what I gave you before: data -= image->pitch * 2; that's assumed you're past the padding! Silly me! what you really want is: data -= image->pitch + (image->w * image->format->BytesPerPixel); Note I only use width here to subtract the bytes you wrote to the buffer -- so my previous statement about never using the width in these kinds of calculations stands... the subtracted width just puts you back to the start of the scanline... and you subtract the pitch to get to the previous scanline. My mistake. Sorry about that. the other assumptions I made pre-edit may be mistaken, however the stuff about the pitch is still a good read so I'll leave it. (edited by Disch on 10-30-05 10:58 PM) (edited by Disch on 10-30-05 11:00 PM) (edited by Disch on 10-30-05 11:06 PM) |
|||
|
Disch Micro-Goomba Level: 4 Posts: 14/16 EXP: 226 For next: 53 Since: 10-21-05 Since last post: 12 hours Last activity: 1 day |
| ||
| The bottom line is nobody should be using NESticle anymore. Even on a very low-end computer, LoopyNES is probably a better option. And on low-medium end computers, the Nester family runs pretty quick. FCEU, NEStopia, VirtuaNES, maybe Nessie <--- should be among the top in everybody's list. There's no 1 clearly superior emu, they all have their pros and cons and it ultimately comes down to user preference. Nintendulator is in a league of it's own. It's definatly the absolute best at what it does... but what it does isn't exactly what most people are looking for. I wouldn't recommend it for casual play, but I don't want to leave it off this list... since it's so great. Nester family (NNNesterJ etc) are a little older and a little more outdated, but are still "decent". However emulation quirks/bugs are obvious in several games (during my last few weeks of using NNNJ, they were becoming more and more glaring to me.. but then again I probably pay a little closer attention than most people). RockNES family (RockNES X, etc) I'd put on a rung just below Nester family. They're good, but I don't think they quite stack up. Various other semi-popular emus are around (namely: JNes) -- I'll NEVER understand why these are popular as they're not nearly as good as any other emu and completely lack features. NESticle, when compared side-by-side with any modern (or semi-modern) emu will look like complete shit. Seriously... anyone still using it needs to give FCEU or something a try for 15 minutes -- you'll be blown away. |
|||
|
Disch Micro-Goomba Level: 4 Posts: 15/16 EXP: 226 For next: 53 Since: 10-21-05 Since last post: 12 hours Last activity: 1 day |
| ||
| Regardless or whether or not you get 0 from that, you should never assume you get zero from that because you didn't specify. In C/C++, uninitialized variables are undefined. They could contain anything. If you really need it to be defined from the get-go. A simple "int var = 0;" will do. |
|||
|
Disch Micro-Goomba Level: 4 Posts: 16/16 EXP: 226 For next: 53 Since: 10-21-05 Since last post: 12 hours Last activity: 1 day |
| ||
Originally posted by Dylan Yoshi I might be selling RockNES short... it is a really good emu. I just always was wooed by NNNJ. I think they're about on par with each other in terms of accurace, but NNNJ has a ton of features and probably more mapper support (but don't quote me on that) |
| Acmlm's Board - I2 Archive - - Posts by Disch |
