It is currently Tue Oct 17, 2017 10:15 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 112 posts ]  Go to page Previous  1 ... 4, 5, 6, 7, 8
Author Message
 Post subject:
PostPosted: Fri Oct 28, 2005 8:15 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 10:59 pm
Posts: 1389
One of my biggest problems with NESASM is that it will not allow you to put more than 8KB of data without manually changing banks - it won't even automatically wrap to the next bank!

_________________
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Oct 28, 2005 9:10 pm 
Offline
User avatar

Joined: Sun Jun 05, 2005 2:04 pm
Posts: 2126
Location: Minneapolis, Minnesota, United States
Okay, I have a question. How could I make a large Map like on Final Fantasy with just a 1 dimensional array? I don't know how I could do this without 2 dimensions, and that's what I hate! things would be SO much easier if 6502 understood 2 dimensions. Any suggestions?


Top
 Profile  
 
 Post subject:
PostPosted: Fri Oct 28, 2005 9:18 pm 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1845
2 dimensions can be easily compacted into 1 dimention by storing things so they're "read like a book". First row, left to right, second row left to right, etc.

Lookup is simple:

(y * width) + x

If the width is a power of 2 value, you can shift the y value left and ORA the x value to accomplish the same task.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Oct 28, 2005 10:08 pm 
Offline
User avatar

Joined: Sun Jun 05, 2005 2:04 pm
Posts: 2126
Location: Minneapolis, Minnesota, United States
Well, yes I know that, but I was wondering how I could make a map that would update the name table 1 column at a time, you know what I mean? I have somewhat of an idea of what I could do, but it wouldn't really work. Yeah, what do you suggest I do? I'm sorry for asking all these questions...


Top
 Profile  
 
 Post subject:
PostPosted: Sat Oct 29, 2005 9:35 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7224
Location: Chexbres, VD, Switzerland
To write a column, just read only the metatiles from the range (xpos+a;ypos-b) to (xpos+a;ypos+b) where a is the size from the middle of the screen (where the player is) and where the border of the screen is horizontally, and b the same vertically.
This formula apply to write the column to the right of the screen, but basically, just by changing signs, you can do the same to write a column on the left, and a row on the top or on the bottom of the screen.

To read the bytes, do it with the formula dish showed, and be carefull with 16-bit additions, indirect adressing, etc... If you do everything right, this would cause no problem (be sure to have a valid map reading routine before having a scrooling routine !!)

Then just write those metatiles at correct PPU adress (that wouldn't be too much complicated, the adress increase by one when scrooling right, increase by 32 when scrooling down, etc... just beware of wrap-arround).

_________________
Life is complex: it has both real and imaginary components.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Oct 29, 2005 4:34 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10046
Location: Rio de Janeiro - Brazil
Celius, let me ask you a question: you know how to draw tiles to the NES screen, don't you? If you understand that there is no reason for you not to understand how a 2D map is represented in memory.

The NES screen is just a 1D representation of a 2D space, just like the game maps. in the screen there are 32 columns. Tile number 0 is the first and number 31 is the last. then, in the next row, the first tile is number 32. The PPU memory is 1D, just like all memories in the world. Yet, you understand that and manages to use the screen just fine.

Unless you don't really understand how the screen works, and manages to get your graphics on the screen by pure luck. Maybe you use a "screen arranger" and never actually got to calculate an address to write to an specifc point in the screen.

Of course you can just go and use the formula we gave you a couple of times already, but this is a very important concept to master.

PLEASE, follow this carefully:

Code:
map/screen (whatever) array:

(row 00) 000 001 002 003 004 005 006 ... 028 029 030 031
(row 01) 032 033 034 035 036 037 038 ... 060 061 062 063
(row 02) 064 065 066 067 068 069 070 ... 092 093 094 095
...
(row 28) 896 897 898 899 900 901 902 ... 924 925 926 927
(row 29) 928 929 930 931 932 933 934 ... 956 957 958 959


This is a representation of a 2D map that's 32x30 in size (the NES screen, for example). Each number is an address (offset, actually) for that particular location in the array. We see it arranged like this, in 2D, but in memory it's all just a long 1D run of values.

The formula we gave you - (y * width) + x - is what you use to find the address of a particular location. In the example above, if we want the 3rd tile in the 3rd row, it would go like this:
(y * width) + x = 2 * 32 + 2 = 66 -> if you look in the grid above, number 066 is indeed the 3rd tile in the 3rd row.
*keep in mind that the 3rd location has an index of 2, as 0 is the first*

The rows are stored one after the other. So, if you want to to read (or write!) something from the 2nd row, you have to skip the first. That's what (y * width) does. "width" is the size of one row, so multiplying it by "y" will skip "y" rows. After that, we already know the address of the row of our interest, now we need to find the specifc element in this row that interests us. We just add "x" now, since each row is linear.

I hope you understand it a little better now.


Top
 Profile  
 
 Post subject: REPLY: Level Design
PostPosted: Sun Oct 30, 2005 9:12 am 
Celius wrote:
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.


Well, i tried to Compile\Assemble it on X816, And it will not compile,
I am making my own clone of SMB out of this code, With Turn
Blocks from SMW and P-switches and stuff! but i still could NOT
assemble it! is there something wrong with the Assembler or the
ASM file itself, or If you have a working MOS\NES assembler that
handles the source code. then email me at: JAJJMM@MSN.COM

Thank you for the source code!
-Hamtaro126 (Mark Sallee)
And please, My real Identity Supposed to be a Secret!


Top
  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 112 posts ]  Go to page Previous  1 ... 4, 5, 6, 7, 8

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 9 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