Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Bregalad

Pages: [1] 2 3 4 5 6 ... 89
Gaming Discussion / Re: Games you want to love but can't
« on: Today at 02:32:16 am »
Final Fantasy -- The first. Sluggish, ugly, tedious and aside from the class/spell system, it is a borefest compared to the later ones. I didn't play it during it's heydey to really see it when it was supposedly innovative.

Also the whole Dragon Quest series. The game themsevles aren't bad, and I like the look/feel/ambiance/athmosphere, however... I do not want to spend hours and hours grinding.

I'll also add the original Castlevania. As a fan of the series I should be a fan of the original... except I'm not, it is extremely hard and very short. Not bad per se, but it feels incomplete.

Gaming Discussion / Re: Will Nintendo target [b]here[/b] next?
« on: September 16, 2016, 02:24:29 pm »
Just in case, BBCode does not work in titles and was never supposed to.

ROM Hacking Discussion / Re: Please remove post, thank you.
« on: September 07, 2016, 03:19:34 pm »
You see - the moderators have some sort of grudge agains repro's...
No only the moderators, I am no moderator and also have a grudge against repros. And against people making profit off other's work in general.

Programming / Re: zsnes hdma mosaic bugs
« on: September 04, 2016, 11:01:24 am »
People still uses zsnes..? It's the nesticle of snes emulation...
Glad I'm not alone thinking this. Nevertheless, ZSNES lacks most of Nesticle's interesting debugging features. Nesticle is *still* the only emulator I think that enables you to chagne CHR-RAM or ROM on the fly during gameplay.

Oh sorry, I tought you were done already. Just please don't forget to give me the script once it's finish :) Compressing it is extremely simple but hacking the game to handle a compressed script can effectively be though I guess - especially with a packed fixed PRG-ROM bank.

So now that this is finished, have you considered compressing the script and see if it'd fit a geniune MMC3 ?

I looked into compressing the graphics, too. With FF1 that'd be easy but the problem is that with FF3 uses a very advanced system for its graphics, every metatile is loaded separatedly and every character is loaded separatedly for sprites. In battle, each monster is loaded individually, and the party's sprites are loaded dynamically as action goes on. This makes graphic compression very difficult for the most part. The ultra-crowded fixed PRG bank doesn't help either.

I'd still be curious to see what is possible to do with text compression.

Many of the games you listed do not use PCM. You even list for example FF1 which do not use DPCM and use noise only for sound effects. Your just listed random NES games. This doesn't make any sense.

The main thing that is killing the industry right now is greed.
This is nothing specific to video game industry, though. Apparently, for some reason, ultraliberalism and extreme greed is very popular among the 1st world elite, even if not su much within the 1st world population. I wonder why.

Also, I can't say if I agree or disagree since I know squat about modern video game industry, but such predictions have already been made over and over on this forum... and for now, they didn't happen.

It's kind of like the Simpsons. You see it as a kid being this amazing thing with massive potential only to watch as it dies a horrible non death and becomes a zombie of it's former self. You pray and pray for God to have mercy and simply kill it, but he never does.
Haha so true. But the same thing can be said about most series (games, comics, books, anime, films, whathever), and it's always the same. So logically the whole things also happens to "video game industry" as a whole...

Video games have stagnated in part because technology has stagnated.
I agree, probably related, the moore's law already ended. We continue to be able to make smaller and smaller chips, but they stopped to be more and more powerful, and massive parallelism is basically useless exept for very specific tasks.

Each generation of consoles was a big step up (or at least a big change) from the generation prior.
I'll also add that games on the same system but begin of life or end of life have almost nothing to do with eachother on earlier generations. Just compare Donkey Kong to Kirby's Adventure, both for the same console. Does early PS2 and late PS2 games have such a difference ? I'd say no.

What do you really get with a PS4 -- just slightly better graphics and/or 4k video.
But 4k video is completely useless for human beings, as the extra resolution isn't even perceptible to the human eye in the 1st place.

Other "innovations" such as immersive 3d or virtual reality are acually a resurect attempt at something that was already a huge commercial failure in the 80s...

Kind of wish this guy continued his video series on NES music tricks and techniques. That shit was really interesting.
Your link is broken.

Nintendo used it for a lot of sound effects (SMB2 and Zelda 1, for example, doesn't use it for music, but most of the sound effects are via DMC)
Such effects were typically done with the FDS channel in the original games, and a cheap, badly sounding, DMC equivalent was introduced in the NES versions.

The soundtrack was composed by Naoki Kodaka. Most NES composers would use the digital channel for sampled drums and the other channels for melodic content, but for Journey to Silius, Kodaka, with the programming assistance of Nobuyuki Hara, Shinichi Seya, and Naohisa Morota used the digital channel for a sampled bassline, and the triangle channel for a kick drum. (Source Wikipedia)
I cannot belive you found something true about Wikipedia when it comes to NES games. So yeah, what it says is exactly the truth, but most of the time, WP is a terrible "reference" when it comes to NES or retro stuff.

This looks very cool ! I look forward to be playing this !

Someone is making a fangame with enhanced graphics and music.


You wouldn't have the script somewhere would you? Just in case they would wanna go with a more accurate translation.
I clearly remember playing a Simons Quest remake on my PC, and it was not this one. It was great, and harder than the NES version.

2. Why do those games come in BIN/CUE files and not ISO images? (A little misleading, don't you think?)
Because games sometimes uses mode 2 sectors where correction data is used as actual data - for their FMVs most notably or for streamed audio music in XA format. Using simple ISO format would only rip the first 2048 bytes of the sector as if it was mode 1 and discard the rest, which would not work.

Programming / Re: GB ASM - Why use a command like 'ld a,a'?
« on: August 21, 2016, 03:52:03 pm »
I know squat about neither Z80 nor 8080 programming, and even less about Gameboy, but wouldn't this set the program status flag to the A register, for example set the zero flag is A is zero, or the negative flag if A is negative ?

Newcomer's Board / Re: What can I do with an expanded SMB1 rom?
« on: August 20, 2016, 10:01:06 am »
You're approaching the problem backwards.  Instead of saying "What can I do with expanded space", start with "what can I do" then you'll know whether or not you'll need to expand for it.  ;P

Reading back from VRAM? Could that cause slowdown/noticeable loading time?
Yes, just like any form of compression.

Don't you need for a fairly large amount of RAM to use LZ encodings? (I know the traditional is a 4KB window but that's a ton of space an NES game is not likely to have). (FF1 used only a small part of the SRAM for actually saving a game but it still used most of the rest of that space for other stuff I think.)
Not if you're compressing graphics, you can read back from VRAM. For any other use, yes, LZ77 is problematic on NES. 4k is an entiere tileset by the way, so the window is probably smaller - I don't remember my program automatically finds the optimal window size using brute force (i.e. compress data with different window sizes and keep the smaller data).

I just quickly did an experiment with FF1's graphics, and it should be able to compress them and save 31% of space using the LZ77 algorithm. Huffman saves only 27%, which is still good but not as good. FF1's graphics use 84kb of the 256kb which makes the rom, after being compressed, they'd use only about 57kb, saving up 26kb for text, more than an entiere bank.

I still didn't manage to do a demo romhack which plays FF1 unaltered but with compressed graphics, but I'll work on it. FF3 uses basiscally FF1's engine with improvements, so it'll work out the same. I suspect FF3's compress ratio will be similar - after compressing the graphics you could also compress text, and then it'll almost surely fir in 512kb.

Gaming Discussion / Re: "New" GBC RPG released.
« on: August 17, 2016, 01:53:42 pm »
I've already seen a preview on Matthew Valente's youtube channel, it really looks amazing! I am most certainly looking forward to playing it.

ROM Hacking Discussion / Re: NES Development Problems, with NMI
« on: August 14, 2016, 03:33:44 am »
When I enabled NMIs with $2000, all of my PPU tile writing routines became garbage.  The screens become messed up.  And when I call my controller write routine from the NMI, my game freezes on the titlescreen when I press one of the controller keys.
Did you actually programm an NMI routine and put its vector at $fffa-$fffb? Did you verify with a debugger or a code logger that it does what you intended it to do?

And a question -- I know how to wait for vblank, by LDA $2002, followed by a BPL back to the LDA $2002, but why do some games, like Megaman for instance, have simply a LDA $2002, and then LDA some other address immediately afterwards?  What is the point to LDA $2002 if you're not going to BPL right afterwards?  What does LDA $2002 do on its own?
$2002 is a PPU registers with 3 used bits in it's upper nybble : Vblank flag, Sprite zero flag and sprite overflow flag, so you can read either of those flags by reading $2002. It's also common to read $2002 but discard it's value to reset the $2005/6 selection flip-flop. The $2005 and $2006 registers actually points to two different registers, the "first" and the "second", every time you write to either $2005 or $2006, the PPU switch a bit internally to indicate which set of registers it's going to write next. Reading $2002 reset this bit and ensures the next write will affect the first set of registers.

Code: [Select]

inc frame_counter
jsr write_joypads
jsr write_spriteRAM
jsr prg_bankswitch
jsr chr_bankswitch
You should definitely save the A, X and Y registers on the stack when writing interrupt routines. The only cases where you can afford not doing that is when you don't use the registers (a rare case), or when the main program actually do nothing (jst a here: jmp here infinite loop).

The reason I'm using the NMI is because I need all of the things that are in the NMI, to be checked constantly.  And all commercial NES games have a frame counter, which from what I've seen, is incremented in the NMI.
There's nothing wrong to use NMI - that's a completely standard way of doing things.

You should really learn to use a debugger - FCEU emulators are awesome for this.

Pages: [1] 2 3 4 5 6 ... 89