It is currently Tue Aug 21, 2018 5:03 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 1451 posts ]  Go to page Previous  1 ... 62, 63, 64, 65, 66, 67, 68 ... 97  Next
Author Message
PostPosted: Thu Mar 21, 2013 5:42 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10719
Location: Rio de Janeiro - Brazil
unregistered wrote:
I can read from $2007... but how do I specify the address? :? (I know the address increments by 1 or 32 after each write to $2007.)

Reading works exactly like writing (set address through $2006, increments of 1 or 32 are still used), except you ignore the first read value.

However, due to the limited duration of VBlank, which would make it nearly impossible to read-modify-write a significant amount of bytes, attribute data is often mirrored in RAM, so that you're free to do all the processing during rendering, and during VBlank you just copy the data to VRAM. Depending on the type of scrolling you use though, it would be much better to just calculate full attribute bytes (i.e. areas of 32x32 pixels) and not have to mirror anything or read-modify-write from/to VRAM.


Top
 Profile  
 
PostPosted: Thu Mar 21, 2013 9:20 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 908
Location: cypress, texas
tokumaru wrote:
unregistered wrote:
I can read from $2007... but how do I specify the address? :? (I know the address increments by 1 or 32 after each write to $2007.)

Reading works exactly like writing (set address through $2006, increments of 1 or 32 are still used), except you ignore the first read value.

However, due to the limited duration of VBlank, which would make it nearly impossible to read-modify-write a significant amount of bytes, attribute data is often mirrored in RAM, so that you're free to do all the processing during rendering, and during VBlank you just copy the data to VRAM.
Ah ha! :D Thank you tokumaru! I totally forgot that my attribute data should already be mirrored in RAM! Tomorrow will be a full working all day day for me! :D


Top
 Profile  
 
PostPosted: Sat Mar 23, 2013 4:17 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 908
Location: cypress, texas
Here is another thing I'm not sure how to fix:

Code:
  draw_RAMbufferColors:
      ;        lda RAMbufferColors, x    ;<this is ordered differently from its attribute table array...
   ;     sta PPUDATA7              ; ...2xF8, 2xD8, 2xF0, 2xD0, 2xE8, 2xC8, 2xE0, 2xC0
   ;     dex                       ; it's upside down or backwards... so we decrement
      ;should be labeled draw-to-RAMbufferColors
     ;and this should always be run right after draw_RAMbuffers... so the screen is already loaded
     sta $ff
     lda CurrentColumn
      lsr a ; / by 2
     sta t2
     lda #$07
     sta t2+1
    
     lda CurrentColumn
     tay
     and #00000001b
     bne +arightColumn
 --   lda ($10), y
     tax
     lda MetatileRhombus, x
     and #$03
     sta upleftAA
     clc
     tya
     adc #$10 ;increment y by 16
     tay
     lda ($10), y
     tax
     lda MetatileRhombus, x
     and #$03
     ldx #$04 ;need to shift left 4 times...
     jsr shift_left
     sta loleftCC
    
     lda t2 ;CurrentColumn
     clc ; <?
     tay
     adc #$08 ;increment t2 by 8
     sta t2
     lda attributes, y 
     and #11001100b ;now the accumulator holds old BB and DD
    
     dec t2+1
     ora upleftAA
     ora loleftCC
     ldx t2+1
     sta RAMbufferColors, x
     sta attributes, y
     bpl --
     jmp +;end
    
 +arightColumn:
 --   lda ($10), y
     tax
     lda MetatileRhombus, x
     and #$03
     ldx #$02 ;must shift left twice...
     jsr shift_left
     sta uprghtBB ;<new
     clc
     tya
     adc #$10 ;increment y by 16
     tay
     lda ($10), y
     tax
     lda MetatileRhombus, x
     and #$03
     ldx #$06 ;need to shift left 6 times...
     jsr shift_left
     sta lorghtDD ;<new
    
     lda t2 ;CurrentColumn
     clc ; <?
     tay
     adc #$08 ;increment t2 by 8
     sta t2
     lda attributes, y 
     and #00110011b ;now the accumulator holds old AA and CC
    
     dec t2+1
     ora uprghtBB
     ora lorghtDD
     ldx t2+1
     sta RAMbufferColors, x
     sta attributes, y
     bpl --

    + rts ;end of draw_RAMbufferColors


What I just changed is the very bottom; it used to say
Code:
ldx t2+1
     ora uprghtBB
     ora lorghtDD
     dex
     sta RAMbufferColors, x
     sta attributes, y
     stx t2+1
     bpl --


But after thinking about it for a bit... those ldx and stx are 3 cycles each and the dex is 2 cycles... and it makes more sense to use less bytes of code... so since the dec is 5 cycles the changes make 0 extra cycles and there's less lines of code that are annoying... it's better, i think. But now the column I'm playing with moved four blocks down on FCEUX 2.1.5s "Name Table Viewer"

In my head it seems like the problem is beyond this code... but could you check and see & report back any errors or improvements you see? :)

edit:
tokumaru wrote:
Depending on the type of scrolling you use though, it would be much better to just calculate full attribute bytes (i.e. areas of 32x32 pixels) and not have to mirror anything or read-modify-write from/to VRAM.
Ok, I agree, though this is what my code
suposedly does above... it basicly initalizes some variables at the top and then a branch decides which loop to enter... the top loop draws the left side of an attribute column and substitutes recent values from my attribute ram buffer for the right side. The bottom loop does the exact same thing invertedly... it draws the right side with its palettes and then substitutes the left side with values from the attribute RAM buffer. It seems like it would be a good try. :oops: :)

edit2.

edit3: Ok I'm sorry tokumaru for saying I agree in my first edit... now I realize you mentioned, "not have to mirror anything" and that's exactly what I've done with my RAM buffer. And so now it seems awful of me to start a reply with "I agree" and then continue to describe my ideas that negate what you talked about. I lied and I'm sorry for doing so. :( :oops:

edit4: After spending a lot of time with this code I would like to say that I was also mistaken in my explanation of my code... the code doesn't draw the columns of tiles... it draws the colors stored in the metatile arrays... or maybe it would make more sense to say that my code up there will write the correct background palette attributes to each 16x16 metatile in singular columns.


Top
 Profile  
 
PostPosted: Wed Mar 27, 2013 1:32 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 908
Location: cypress, texas
tepples wrote:
unregistered wrote:
I didn't know RAM can overlap

There are two kinds of assembly language programmers: those who have written a buffer overflow and those who have yet to.


I just figured my problem out! It was another buffer overflow, I think. What was wrong was my change of bne to bpl; it's not magic! :D What happened was that In my code at the end
Code:
     dec t2+1
     ora upleftAA
     ora loleftCC
     ldx t2+1
     sta RAMbufferColors, x
     sta attributes, y
     bpl --

that code... the problem was that my CurrentColumn variable is at $0070 and next is my array RAMbufferColors. Changing the bpl back to bne solved the problem... because What happened was that the bpl ran the x variable to #$FF and that made the sta RAMbufferColors, x change the value of CurrentColumn to 64... and that drew the column four squares below. :D I'm so happy I could figure this out! :D :mrgreen:

text added in my edit.


Top
 Profile  
 
PostPosted: Fri Apr 05, 2013 3:52 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 908
Location: cypress, texas
I increased the increment added to my screen's scroll each frame from 1 to 4... and now the screen scrolls quite fast and my character speeds up too! :shock: Why? :? I'm trying to make my game more like a real game where like Mario, he never reaches the edge of the screen... cause it scrolls as fast as he runs. Our lady always reaches the edge of the screen and then appears on the other side of the screen. I speeded up the scroll to try and prevent this and our lady increases her speed while the screen is scrolling so she reaches the edge anyway! :x :(

edit: I haven't found code that was written to speed her up. How do I slow her down? :? Thank you for reading this. :)


Top
 Profile  
 
PostPosted: Fri Apr 05, 2013 4:32 pm 
Offline
User avatar

Joined: Wed Apr 02, 2008 2:09 pm
Posts: 1181
Impossible to know without seeing your movement code.

The camera should be totally separate from how your character moves. She'll move as fast as she's programmed to. That's it for that.

Later in the code, you decide to move the camera based on where she is. Like... if her position is greater than half the screen, the camera moves to her position - 128 (half the screen).

So... cameraposition = ladyposition - 128.
If cameraposition > levellength -256, cameraposition = levellength-256.
If cameraposition < 0, cameraposition = 0.


If cameraposition/8 - oldcameraposition/8 is not equal to 0, we moved at least one tile and need to update the nametables.

You can do some more trick types of scrolling, like having the camera only move forward when she's say... 16 pixels to the right of the middle, and only move back when she's 16 pixels from the left of the middle. (So running back and forth in the middle would not cause jerky scrolling), but above is the super basics that are easy to adapt to things like that.

_________________
https://kasumi.itch.io/indivisible


Top
 Profile  
 
PostPosted: Fri Apr 05, 2013 6:48 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 908
Location: cypress, texas
Kasumi wrote:
Impossible to know without seeing your movement code.

The camera should be totally separate from how your character moves. She'll move as fast as she's programmed to. That's it for that.

Later in the code, you decide to move the camera based on where she is. Like... if her position is greater than half the screen, the camera moves to her position - 128 (half the screen).

So... cameraposition = ladyposition - 128.
If cameraposition > levellength -256, cameraposition = levellength-256.
If cameraposition < 0, cameraposition = 0.


If cameraposition/8 - oldcameraposition/8 is not equal to 0, we moved at least one tile and need to update the nametables.

You can do some more trick types of scrolling, like having the camera only move forward when she's say... 16 pixels to the right of the middle, and only move back when she's 16 pixels from the left of the middle. (So running back and forth in the middle would not cause jerky scrolling), but above is the super basics that are easy to adapt to things like that.
Kasumi, incredible response! Thank you a bunch! :D

Oh my movement code isn't very any good... that's going to change though! :D

added in edit


Top
 Profile  
 
PostPosted: Sat Apr 06, 2013 8:13 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 908
Location: cypress, texas
Kasumi wrote:
Later in the code, you decide to move the camera based on where she is. Like... if her position is greater than half the screen, the camera moves to her position - 128 (half the screen).
Woah... Kasumi, that changes my entire view on this. Right now our game starts out drawing my sister's first two nametables and attribute tables. My most recent goal has been to successfully scroll into a third screen. So far I have code that draws two 8 bit wide columns... and the attribute tables part isn't working for some reason... but, you just have to specify a value 0 through F and the selected 16 bit wide column will be drawn correctly! Now my next step was to achieve scrolling into a third screen, but you have changed that... my new next step goal is to set the game so that the camera adjusts to our ladie's starting point in the level. This is going to require more thought but it's a new goal - I'm satisfied with it! :D


Top
 Profile  
 
PostPosted: Sat Apr 06, 2013 8:54 pm 
Offline
Formerly 65024U

Joined: Sat Mar 27, 2010 12:57 pm
Posts: 2262
I believe you should work with a single table, if your game scrolls one way. Use basically a revolving door. Keep the next column, bytes of attributes to update, etc. in a RAM buffer. You don't need to look at it as two screens and you scroll to a third, it's a single screen that you scroll to another on. :) Basically, keep either 30 or 60 bytes (One or two columns vertically) of tiles to write to wherever they go, and then eight bytes or however many for the updated attribute data that you need to add after. Shove it all to the PPU, but then also shove it to a big "Nametable Current" buffer that is like a binary number, when it overflows, it doesn't go to the "2nd nametable" row then back to the first. It would go back onto it's self, so you basically only have one screen of data in it at a time...I mean, unless you're showing two screens at once. :) But I mean if that works, you can keep it like that, I don't exactly know how your engine is set up, that way might be better for what you have, but I'm not sure. Just my input on that. It's something that if it works, I wouldn't change it. But you can do it later if you want to save RAM, or just to change how the scrolling works.


Top
 Profile  
 
PostPosted: Mon Apr 08, 2013 9:27 am 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 908
Location: cypress, texas
3gengames wrote:
I believe you should work with a single table, if your game scrolls one way.
Our game will be scrolling both ways... but one way is good at first... I guess. So when scrolling both ways we would use two tables... both in RAM buffers I think.
3gengames wrote:
You don't need to look at it as two screens and you scroll to a third, it's a single screen that you scroll to another on. :)
Yes, that would be the point of switching to where the lady starts... :) it's a solid level... starts at 0 and then ends at something like 1024.
3gengames wrote:
but then also shove it to a big "Nametable Current" buffer that is like a binary number, when it overflows, it doesn't go to the "2nd nametable" row then back to the first. It would go back onto it's self, so you basically only have one screen of data in it at a time...
Thank you 3gengames, I think I understand what you mean. :) We will have to have 2 screens of data I think... a lot to think about....


Top
 Profile  
 
PostPosted: Mon Apr 08, 2013 9:42 am 
Offline
Formerly 65024U

Joined: Sat Mar 27, 2010 12:57 pm
Posts: 2262
Yep, don't fudge up this part! But even scrolling 2 ways, 1 buffer will work still. Just have to make the buffer go forward and backward in writes, nothing too bad. Shouldn't be hard to make, compared to most other things. :)


Top
 Profile  
 
PostPosted: Mon Apr 15, 2013 4:52 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 908
Location: cypress, texas
How do I draw on the nametable that's not shown? If the screen starts out on nametable #0... the next column drawn would be column 0 on nametable #1 right?


Top
 Profile  
 
PostPosted: Mon Apr 15, 2013 4:59 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20434
Location: NE Indiana, USA (NTSC)
To draw on column 0 of nametable #1:
  1. Wait for the start of vertical blanking.
  2. Set the VRAM increment to +32.
  3. Set the VRAM address to $2400, or $2480 if you have a top status bar.
  4. Write a bunch of bytes.
Where you draw doesn't depend on the scroll position because you're going to set the scroll position again before the end of vblank.


Top
 Profile  
 
PostPosted: Mon Apr 15, 2013 7:48 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 908
Location: cypress, texas
tepples, thank you. :)

unregistered wrote:
How do I draw on the nametable that's not shown? If the screen starts out on nametable #0... the next column drawn would be column 0 on nametable #1 right?

No no... so I should draw column 0 of nametable 0... after i've scrolled to nametable #1... Would column 0 of nametable 0 be the start of the third screen? Maybe?


Top
 Profile  
 
PostPosted: Mon Apr 15, 2013 8:04 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10719
Location: Rio de Janeiro - Brazil
unregistered wrote:
Would column 0 of nametable 0 be the start of the third screen?

Yes.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 1451 posts ]  Go to page Previous  1 ... 62, 63, 64, 65, 66, 67, 68 ... 97  Next

All times are UTC - 7 hours


Who is online

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