It is currently Sun Oct 22, 2017 4:02 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 112 posts ]  Go to page 1, 2, 3, 4, 5 ... 8  Next
Author Message
 Post subject: Level designing
PostPosted: Wed Jul 27, 2005 4:02 pm 
Offline
User avatar

Joined: Sun Jun 05, 2005 2:04 pm
Posts: 2131
Location: Minneapolis, Minnesota, United States
I've been messing around with arranging backgrounds, and each of the methods I've used have proven to be unreliable. I tried the method that was used to design the level for the Junkdemo by charles doty, and that has proven to be GLITCHY. Nintendulator goes phsyco when you load the rom that you made, and virtuaNes doesn't do it correctly, and surprise surprise, nesticle screws it up. It works on Jnes, but nothing else. And the other method is loading a .nam file, which only works on Jnes as well. On all the other emulators, it's like it scrolled down, and stopped at name table 1.5, if you know what I mean. I had to use a crap method to save name table space. I made a Final Fantasy VII Nes screen, and I just took the font they used on the ff2 titlescreen, and arranged it with tepples version of NSA, so it said Final Fantasy, then I put the Burning Earth inbetween Final and Fantasy. There wasn't enough room to have just Final (burning earth) Fantasy, so I had to have a peice of Fantasy written, and then load the other missing letters as sprites. It was bad. I don't even know why I'm talking about that, so I will stop. But does anyone know a reliable way to design levels? :)


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jul 27, 2005 4:14 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19115
Location: NE Indiana, USA (NTSC)
If you're designing levels, not title screens, then you will usually write a custom editor designed specifically for the model of the world used in your game engine.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jul 27, 2005 4:35 pm 
Offline
User avatar

Joined: Sun Jun 05, 2005 2:04 pm
Posts: 2131
Location: Minneapolis, Minnesota, United States
Well, that would be nice, but I would prefer not to have to .incbin so many files. Do you know a method they use in games such as smb1? That method has to be reliable, and they don't have to incbin anything. I should go study that code right now.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jul 28, 2005 6:29 am 
Offline
User avatar

Joined: Tue Jul 12, 2005 4:37 pm
Posts: 121
Celius wrote:
Well, that would be nice, but I would prefer not to have to .incbin so many files. Do you know a method they use in games such as smb1? That method has to be reliable, and they don't have to incbin anything. I should go study that code right now.


Actually, they probably .incbinned a whole bunch. You should only use .db and .dw for shorter byte/word additions, because otherwise the whole code page just gets cluttered. I'm not sure how they stored levels in SMB1, but they most certainly did at least one .incbin with all the level data in it.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jul 28, 2005 11:17 am 
Offline
User avatar

Joined: Sun Jun 05, 2005 2:04 pm
Posts: 2131
Location: Minneapolis, Minnesota, United States
Well, they don't in this particular dissassembly of Mario: http://pics.pineight.com/nes/smb1_src.zip The code is very long I must admit, but they pull of not having to incbin a bunch of files. But I don't know if I could make a reliable program for making levels. I can't even make a good titlescreen. when you .incbin a .nam file, it screws up alot. I don't know if it's the code, or what. It just screws up on every emulator besides Jnes. is there a way to make charles doty's junkdemo code reliable?

Code:
mazer:
        lda #$20        ;
        sta $2006       ; Set start address to Name Table #1
        lda #$00        ;
        sta $2006       ;
        ldx #$00        ; Set X insty to 0

beg:
        ldy maze,x      ; Load Y insty with "maze" + X offset

rep:
        lda #$01        ; begin 1st cycle of writing $01 to the name table
        sta $2007       ; the number of times in the Y register
        dey             ; Decrement Y and
        bne rep         ; Repeat if Y is not yet zero
        inx             ; Increment X and
        ldy maze,x      ; Read the next maze value into the Y register

repa:
        lda #$00        ; begin 2nd cycle of writing $00 to the name table
        sta $2007       ; the number of times in the Y register
        dey             ; Decrement Y and
        bne repa        ; Repeat if Y is not zero
        inx             ; Increment X
        cpx #252        ; right now the routine quits after 252 maze values
        bne beg         ; repeat the 1st & 2nd cycle if X isn't yet 252
        rts

    .db 64
    .db 3,1,14,1,5,1,5,2
    .db 3,1,14,1,5,1,5,3
    .db 2,1,2,10,2,1,2,1,2,1,2,1,2,3
    .db 2,1,5,1,5,1,2,1,2,1,2,1,2,1,2,3
    .db 2,1,5,1,5,1,2,1,2,1,2,1,2,1,2,3
    .db 2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,3
    .db 2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,3
    .db 2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,3
    .db 2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,3
    .db 2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,3
    .db 2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,3       
    .db 2,1,2,1,2,1,2,1,2,1,5,1,2,1,2,1,2,3
    .db 2,1,2,1,2,1,2,1,2,1,5,1,2,1,2,1,2,3   
    .db 2,1,2,1,2,1,2,1,2,7,2,1,2,1,2,3       
    .db 5,1,5,1,14,1,2,3     
    .db 5,1,5,1,14,1,2,34


I wonder what's so unreliable about this... well, the sprites position being updated during the pause routing, making it's movement visible one pixel at a time by just having a bunch to of NOP being jumped to like 46 million times and returning after that to move one more pixel and do it again seems pretty reliable, haha. That's very unreliable. I don't know about this bg code though. You don't want to see my version of this code running in Nintendulator. It looks like a frickin hurricane. And virtuaNES puts all the tiles in the wrong place. NESticle and Jnes do the Junkdemo right, and Jnes does my code, but not NESticle. I was wondering how the heck you could get a C program to output that hibber jibber you see when you open a .nam file in Notepad? If I knew how to output reliable code for the NES to output on the screen, I would just stop this whole thing and make my own level editor, which I would like to do, but I'm afraid i wouldn't know how to put it in my code. That didn't make much sense. Well, i'm going to go. bye.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jul 28, 2005 12:08 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19115
Location: NE Indiana, USA (NTSC)
Delete nesticle. Now.

Nintendulator is the only emulator you should ever be worried about.

Junk Demo was made before almost anybody had access to hardware devkits and should not be relied upon as a good example.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jul 28, 2005 12:31 pm 
Offline
User avatar

Joined: Tue Jul 12, 2005 4:37 pm
Posts: 121
It looks like your problem is that you did not read from $2002 before writing to $2006.

Remember,

ALWAYS READ FROM $2002 BEFORE WRITING TO $2005/$2006! READING FROM $2002 RESETS $2005/$2006 TO THE HIGH BYTE, SO YOU CAN RELIABLY WRITE TO THEM!

NESticle is very forgiving about forgetting to do this, making it a bad emulator to test on, but most emulators are not, for good reason.

So your code should look like this:

lda $2002
lda #$20
sta $2006
lda #$00
sta $2006

----

With the level thing, you're talking about a disassembly of the program, which doesn't use any .incbins. Nevertheless, the original assembly code probably does, because it would be quite a job putting in all those .dbs.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jul 28, 2005 12:36 pm 
Offline
User avatar

Joined: Tue Jul 12, 2005 4:37 pm
Posts: 121
tepples wrote:
Delete nesticle. Now.

Nintendulator is the only emulator you should ever be worried about.

Junk Demo was made before almost anybody had access to hardware devkits and should not be relied upon as a good example.


That's not quite true, at least not for me. Nintendulator is very accurate (except regarding the Frame IRQs), but it is slow as a result. It should only be used for hacking. FCEU should be used for general gaming.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jul 28, 2005 1:48 pm 
Offline
User avatar

Joined: Sun Jun 05, 2005 2:04 pm
Posts: 2131
Location: Minneapolis, Minnesota, United States
I'm sorry, I will always keep NESticle to play FF3 on, but only for that reason. I don't have fun playing it on any other emulator. I really wish NESticle was accurate at all, because I love the setup, but too bad it's a peice of CRAP. It runs FF3 well, and that's the only reason I will keep it. But I will update my code and see if it works. :)


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jul 28, 2005 2:02 pm 
Offline
User avatar

Joined: Sun Jun 05, 2005 2:04 pm
Posts: 2131
Location: Minneapolis, Minnesota, United States
beneficii wrote:
Quote:
lda $2002
lda #$20
sta $2006
lda #$00
sta $2006


uhh, when you lda twice in a row, doesn't it just skip what you previously loaded? when you loaded $2002, you loaded #$20 right after it, so wouldn't that just skip $2002? :|


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jul 28, 2005 2:11 pm 
Offline
User avatar

Joined: Tue Jul 12, 2005 4:37 pm
Posts: 121
Celius wrote:
beneficii wrote:
Quote:
lda $2002
lda #$20
sta $2006
lda #$00
sta $2006


uhh, when you lda twice in a row, doesn't it just skip what you previously loaded? when you loaded $2002, you loaded #$20 right after it, so wouldn't that just skip $2002? :|


It will, because the value of $2002 at that point is unimportant to your program. The reason you need to read from $2002 is to reset $2006; if you don't, then $2006 will be, to use your term, unreliable. If, after you write to $2006, you want to do it again, then you need to read from $2002 again (except in certain special cases).

Look through the source code of any Nintendo game: they will always have some sort of read from $2002 before writing to $2005/$2006.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jul 28, 2005 2:13 pm 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1845
doing a $2002 read resets the ppu write toggle (so the next write to $2005/6 will be the first write -- not the second write). That's the point he was trying to make. The value read from $2002 doesn't really matter here (and so it can be discarded with the following LDA).

Example:

Code:
LDX #$20
LDY #$00

; normal behavior

LDA $2002  ; reset toggle
STX $2006  ; this is the first write (high byte PPU addr)
STY $2006  ; this is the second write  (low byte PPU addr)

; Toggle resetting example

LDA $2002 ; reset toggle (not really necessary here, but whatever)
STX $2006 ; first write
LDA $2002 ; reset toggle again
STY $2006  ; FIRST write -- not second write (toggle was just reset)




EDIT --
doh -- I reply too slow, he already answered XD


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jul 28, 2005 2:42 pm 
Offline
User avatar

Joined: Sun Jun 05, 2005 2:04 pm
Posts: 2131
Location: Minneapolis, Minnesota, United States
Ohh, I think I get it. Well, it was a little more reliable, but I think I would be better off making my own level editor. That's going to take a while. i think I will try and make a level editor that writes to all name tables instead of just one. And maybe I'll have a scanline sort of thing where when you cross over it, it rewrites the data for the name tables that are offscreen. Do you know what I mean? like this:

---------------------------------
l nt1____l__nt0__l_nt1__ l
lllllllllllllllllllllllll xlllllllllllllllllllllllllll
---------------------------------
l_nt3___l__nt2__ l__nt3__l
llllllllllllllllllllllllllxlllllllllllllllllllllllllll
---------------------------------

where the x is the scan line thing, and when you cross over it, it resets the data in nt1 and nt3, and if you cross over it the other way, it will reset the data in nt1 and nt3 again, for making large levels. Do you think this is possible? :) I need to study C a little more and I need to have it put out hibber jibber that the NES can read well. That's gonna be really hard.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jul 28, 2005 2:55 pm 
Offline
User avatar

Joined: Tue Jul 12, 2005 4:37 pm
Posts: 121
Disch wrote:
doing a $2002 read resets the ppu write toggle (so the next write to $2005/6 will be the first write -- not the second write). That's the point he was trying to make. The value read from $2002 doesn't really matter here (and so it can be discarded with the following LDA).

Example:

Code:
LDX #$20
LDY #$00

; normal behavior

LDA $2002  ; reset toggle
STX $2006  ; this is the first write (high byte PPU addr)
STY $2006  ; this is the second write  (low byte PPU addr)

; Toggle resetting example

LDA $2002 ; reset toggle (not really necessary here, but whatever)
STX $2006 ; first write
LDA $2002 ; reset toggle again
STY $2006  ; FIRST write -- not second write (toggle was just reset)




EDIT --
doh -- I reply too slow, he already answered XD


That was the point she was trying to make, she already answered. :D


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jul 28, 2005 2:56 pm 
Offline
User avatar

Joined: Tue Jul 12, 2005 4:37 pm
Posts: 121
Celius wrote:
Ohh, I think I get it. Well, it was a little more reliable, but I think I would be better off making my own level editor. That's going to take a while. i think I will try and make a level editor that writes to all name tables instead of just one. And maybe I'll have a scanline sort of thing where when you cross over it, it rewrites the data for the name tables that are offscreen. Do you know what I mean? like this:

---------------------------------
l nt1____l__nt0__l_nt1__ l
lllllllllllllllllllllllll xlllllllllllllllllllllllllll
---------------------------------
l_nt3___l__nt2__ l__nt3__l
llllllllllllllllllllllllllxlllllllllllllllllllllllllll
---------------------------------

where the x is the scan line thing, and when you cross over it, it resets the data in nt1 and nt3, and if you cross over it the other way, it will reset the data in nt1 and nt3 again, for making large levels. Do you think this is possible? :) I need to study C a little more and I need to have it put out hibber jibber that the NES can read well. That's gonna be really hard.


It was a little more reliable? Well, did it load or not?


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 112 posts ]  Go to page 1, 2, 3, 4, 5 ... 8  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 16 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group