I'm always happy to try and fix issues when they're brought to my attention. If the problem still happens in the newest version, let me know. There should be a button along the lines of "More Info" or "Error Details" when the program crashes. If you copy and paste those details it will help a lot.
It's not that obvious in fact...I know it's strange but that's what they did.
I'm not really clear on what your point is. I do understand how it works under the hood (I think). I was simply stating that palette RAM, in particular, is memory used for video that is accessed via the PPU address/data lines. My understanding of a "bus" might not be 100% accurate, so I'll give you the benefit of the doubt and assume that I'm technically wrong, because who really cares? We're talking about a VWF, not palette RAM.
1) If a dialog is very small and uses less than 8 letters per line, a VWF can be made with sprites 2) If a dialog uses the entire screen width and that the main game uses only a single nametable, and that the total VWF area (not including whitespaces) is not more than 30 pixels in heighth, it is doable with CHR-ROM and raster timing. By having a 4k CHR-ROM page where each tile is simply it's number shown in graphics (I'm not sure how to tell this, tile #0 would be blank, tile #1 would have only a single white pixel, and tile #255 would have a entiere horizontal line), it's possible to draw arbitrary graphics by changing the vertical scroll every line.
Number one seems far to restrictive to be practical. I guess it could be used for menus or something. Number two is actually pretty clever, in a Rube Goldberg sort of way. Kudos to you if you get something like that up and running in an actual game, and if it suits you, why not? I'd personally sooner convert a game to use CHR RAM if possible.
Actually CHR-ROM is suitable for VWF but it's quite complex and would require to pull off some dirty trick of the NES to make it work.
This I would like to hear more about, but I think "quite complex"/"dirty trick" is the difference between "possible" and "suitable". The only possibility I can think of is building pre-rendered bits of VWF and pasting them together.
What do you mean when you say VRAM? You have OAM RAM and nametable/attribute RAM, which are found inside the NES, and a cart will use either CHR RAM or CHR ROM. Other than CHR ROM, those can all be considered VRAM. I'm guessing you mean CHR RAM, since that's generally the only VRAM that's optional.
Not sure exactly what you're getting at either. Are you looking to implement a VWF? Kawa no Nushi Tsuri uses CHR ROM, which isn't suitable for a VWF. It might be possible to hack it to use CHR RAM. I don't see any CHR swapping happening while video output is on.
By the way Snarf, is the video you posted a Let's Play or you gave it a few tries before recording? If it's your first time, I can say it's quite amazing that you got that far. Hats off. The only thing that sucks with Contra video recordings is how the bullets flicker and therefore not always appear in the recording frame. It means you are always seeing only part of the total bullets on screen and it's visually annoying...
I ran out of continues once, and then got to the boss on my next try, so no, not that amazing. I was impressed with myself the next day when I managed to beat both levels without using any continues, though.
And, yeah, the invisible bullet issue is annoying. I've managed to blend even and odd frames together using Avisynth, which produces perfect results on YouTube, but I kept running into audio issues (missing or out of sync), so I gave up on that.
I don't like the idea of voting to determine what gets approved. Approval isn't a popularity contest. If it follows the rules and it's at all reasonable, it should be approved. With voting, things may get turned down that shouldn't be, and things can easily be approved even when they go against guidelines. Also, it just invites too many chefs into the kitchen.
I'm not too big on the idea of limits, either, for exactly the reason KingMike gave. Quantity is not necessarily the best metric to determine if a user's submissions are quality. If there are users who have a habit of making many pointless or inappropriate submissions, they should be politely reminded of the rules and how their behavior affects staff and the website.
Well, I actually was considering asking if you would want me on staff. I know I wasn't terribly interested before, but given the current state of affairs, I'm happy to do what I can to push things in the right direction.
Oh, and more good news. I found a way to expand the ROM successfully, and with minimal change to the original code.
Good news indeed.
Your energy zone remake turned out excellent, especially given the little this level offered to begin with. It's much more open than the other levels, but still by no means easy. I've yet to beat it, but I got to the boss.
Keep up the amazing work. Can't wait for the finished product!
Made this a very long time ago, but I never shared it because it was buggy and complicated. Apparently, I called it both "Combificator" and "Combulator". Neither name really makes much sense, which seems fitting.
Ignore the numbers
It's a tool to edit the vertical strips used to construct screens in The Legend of Zelda. The source is included. It can be of some limited usefulness in conjunction with my overworld editor.
More info at http://snarfblam.com/words/?p=444. June 10, 2013, 09:37:45 pm - (Auto Merged - Double Posts are not allowed before 7 days.)So, here is a new version of my Metroid editor. This version allows you to add ASM to each screen that will run when the screen loads. It includes a built-in assembler so you can do everything right in Editroid.
This makes it easy to do things like bankswap graphics for different areas of a level or change music for different areas, or to load additional objects into the screen based on a condition, or change the lava height in different screens so it doesn't have to be right at the bottom in every screen. So yeah... all sorts of stuff.
This is an alpha version, meaning everything is implemented and works, but hasn't been tested and debugged too thoroughly, but I've been using it without any problems.
Before you start adding ASM, the ROM needs to be expanded (under the file menu), and then you can click "Create Project" in the project menu. Then, everything ASM-related can be found in the project menu.
; This is required by the above example. ; This would be placed in the general code file.
; ---------------------------- ; ExtraRoomData ; ---------------------------- ; Draws additional objects to a screen. Call in screen-load ; routine. This is a modified version of a similar routine in ; the original game. ; Parameters: ; x - low byte of object data ; y - high byte of object data
ExtraRoomData: stx RoomPtr ; Store data address sty RoomPtr + 1 ldy #$00 ; Point to first byte lda (RoomPtr),Y ; Read it
DrawExtraObject: sta $0E ;Store object position byte(%yyyyxxxx). lda CartRAMPtr ; sta CartRAMWorkPtr ;Set the working pointer equal to the room pointer--> lda CartRAMPtr+1 ;(start at beginning of the room). sta CartRAMWorkPtr+1 ; lda $0E ;Reload object position byte. jsr Adiv16 ;($C2BF)/16. Lower nibble contains object y position.--> tax ;Transfer it to X, prepare for loop. beq +++ ;Skip y position calculation loop as y position=0 and--> ;does not need to be calculated. * lda CartRAMWorkPtr ;LoW byte of pointer working in room RAM. clc ; adc #$40 ;Advance two rows in room RAM(one y unit). sta CartRAMWorkPtr ; bcc + ;If carry occurred, increment high byte of pointer--> inc CartRAMWorkPtr+1 ;in room RAM. * dex ; bne -- ;Repeat until at desired y position(X=0).
* lda $0E ;Reload object position byte. and #$0F ;Remove y position upper nibble. asl ;Each x unit is 2 tiles. adc CartRAMWorkPtr ; sta CartRAMWorkPtr ;Add x position to room RAM work pointer. bcc + ;If carry occurred, increment high byte of room RAM work--> inc CartRAMWorkPtr+1 ;pointer, else branch to draw object.
;CartRAMWorkPtr now points to the object's starting location (upper left corner) ;on the room RAM which will eventually be loaded into a name table.
* iny ;Move to the next byte of room data which is--> lda (RoomPtr),y ;the index into the structure pointer table. tax ;Transfer structure pointer index into X. iny ;Move to the next byte of room data which is--> lda (RoomPtr),y ;the attrib table info for the structure. sta ObjectPal ;Save attribute table info. txa ;Restore structure pointer to A. asl ;*2. Structure pointers are two bytes in size. tay ; lda (StructPtrTable),y ;Low byte of 16-bit structure ptr. sta StructPtr ; iny ; lda (StructPtrTable),y ;High byte of 16-bit structure ptr. sta StructPtr+1 ; jsr DrawStruct ;($EF8C)Draw one structure.
; Next Object lda #$03 ;Move to next set of structure data. jsr AddToRoomPtr ;($EAC0)Add A to room data pointer. ldy #$00 ;Zero index. lda (RoomPtr),y ;Load byte of room data.--> cmp #$FF ;Is it #$FF(end-of-room)?--> beq + ;If so, branch to exit. jmp DrawExtraObject * rts
There's been a big issue lately with quality vs. quantity. I've seen a huge number of pointless submissions, and lots of things that don't belong here being approved, presumably because the staff can't scrutinize the submissions given the volume. It's great that people want to contribute, but it's frustrating when it's done without discretion.
What sets battle kid apart is that it is comparatively new. If I recall correctly, RHDN generally stays away from current gen consoles. Like I said, I'm not sure about the policy, and of course NES is plainly not current gen, but the game in question is right on par with current gen as far as newness goes.
Honestly, my bigger concern is how Sivak would feel about it. The world of NES homebrew is not very far removed from what a lot of us do here, and from what I understand, he's not too keen on the idea of Battle Kid ROMs floating around. Releasing a hack for his game might be like thumbing our collective nose at him.
I just thought I would point it out in case it got overlooked. If that's not the case then the staff is free to tell me to shut up and mind my own business.
I've seen some similar things before, but never on such a magnificent scale. I can only imagine it's the product of a macro or tool, though, and going back and making code prettier doesn't pay the bills, so that's what we get.
Shin Zelda Densetsu doesn't seem to save for me. If I die and choose "save", I can continue from that save as long as I don't power off, but if I turn off the game and come back to it later, the save is gone.
Check the header of the ROM to see if it is battery backed. This is easy to do with the message log in FCEUX. This is what I'm seeing:
Any thoughts about adding ROM/ISO info that's missing to Public Maintenance?
While it would be nice to have, if the info's not there in the first place, where are you going to get it? Realistically, I think the current approach is the best solution, provided submitters (and approvers) abide by the guidelines.
I fail to see how you could NOT BOTHER having to repeat the same thing again and again.
Well, that's probably because not everybody is you.
Dragon Warrior was the first RPG I ever played. As a kid, I found it necessary to grind for at least a few hours to beat the game. I didn't mind at all, but I would certainly still call it grinding. I felt a certain sense of accomplishment. These days I'm not nearly as patient with games, and that sort of thing strikes me as a serious balancing/design flaw. Even one person's perspective can vary greatly over time. Even today there are certain situations where I might consider something "grinding" but don't mind, depending on what kind of mood I'm in.