Changing background image, palette after the event

[belltone]

How can such that when I click on the button Press Start then loaded to another background picture such as games or other sprites palette as much as possible to make the transition.

How can I change the palette, background, sprites after what some events there any lessons?
It is also useful to create levels.

I wrote a simple engine and then do not know what to do.
I would like to upload another file to *nam when pressed.

[tokumaru]

The normal way to handle screen transitions is to implement separate program modes. The title screen is one program mode, the main game is another, and so on. Each program mode has its own setup code (which draws name tables, changes palettes, etc.), its own frame logic (which reads input, updates objects, etc.), and sometimes its own NMI handler.

To switch from one mode to the other, all you have to do is jump to that mode's initialization code, which will take care of setting up everything, including name tables and palettes.

[Drag]

Yep, and this method of designing your program is called a "finite-state machine". You might have a program with the following states:

• Title screen
• Password screen
• Stage intro
• Gameplay
• Stage outtro
• Game over screen

Each one of those "states" is a loop. For example, the title screen can wait (in a loop) for the player to press start, then draw a menu and wait for the player to make a selection, with the menu-handling routine being the loop. From there, you might change to the password screen state or the stage intro state.

Like Tokumaru said, changing to another state is as simple as jumping to code that sets up the screen and the memory for that state (can also be called an "entry point", in addition to an "initialization routine"), which then continues into the loop for that state. You can have multiple sub-states within a state, like in my title screen example where you have a "press start" state and a "menu" state, but you can also split the state into two if you like that design better, or you could combine those two sub-states into one loop.

If you want, you can also give each state an "exit point", or some code to run when you leave that state, like fading out the screen, before you jump to the entry point of another state, which could set up the screen then fade it back in.

[belltone]

I understand that this code should be inactive and called on demand.
It would be nice to show the code on the example of how it all called.

I tried to enter the code welcome background after taking NMI RTS and call it in EnginePlaying function using JSR after pressing the Start button, i get a mess of moving zeros.

[Sogona]

Not at a computer currently, but here's off the top of my head how I handle game states. My NMI is currently the same for each state, so I don't have to worry about that.

I have 2 variables, gamestate and gamestatold. Each frame, I compare these two variables, and if they're different, I use the new gamestate variable as an index to jump to the initialization logic, and gamestateold is set to gamestate. Otherwise, it goes on to the main logic for the state. The reason I don't just immediately go to a new state in the middle of logic is that I could be knee-deep in subroutines, and this makes it extremely easy for bugs to happen, and very hard to find them

Here's an example

Code: Select all

        gamestate        .dsb 1
        gamestate_old .dsb 1
        jump_ptr.          .dsb 2


GameStateInits:
        .dw TitleStateInit, PlayStateInit, GameOverInit
GameStates:
        .dw TitleState, PlayState, GameOverState


MainLoop:
        ;increment frame counter
        lda gamestate
        cmp gamestate_old
        beq +
        ;initialize new game state
        sta gamestate_old
        asl         ;*2, use as index to access word table
        tax
        lda GameStateInits,x
        sta jump_ptr+0
        lda GameStateInits+1,x
        sta jump_ptr+1
        jsr IndirectJump
        lda gamestate
+       ;go to main loop of gamestate
        asl
        tax
        lda GameStates,x
        sta jump_ptr+0
        lda GameStates+1,x
        sta jump_ptr+1
        jsr IndirectJump
        ;wait for vblank
        jmp MainLoop


IndirectJump:
        jmp (jump_ptr)


TitleStateInit:
        ;load title screen
        ;play title music
        rts
TitleState:
        ;check if start button is pressed, if so go to play state
        lda buttons_pressed
        and #%00010000
        beq +
        lda #STATE_PLAY
        sta gamestate
+       rts


PlayStateInit:
        ;load level
        ;load objects
        ;play level music
        rts
PlayState:
        ;update objects
        ;update player
        ;respond to controller input
        rts


GameOverInit:
        ;clear variables
        ;show game over screen
        rts
GameOver:
        ;wait for start button to be pressed
        ;if so, either reset game or go back to title state
        rts

[belltone]

Tank you for helping, your code should be placed after the NMI?

I did not work the joystick if I clean it up NMI:

Code: Select all

        lda #%10010000
        sta $2000

        lda #%00001110
        sta $2001

Code: Select all

WelcomeScreen:
        lda $2002
        lda #$20
        sta $2006
        lda #$00
        sta $2006
        lda #<(welcome)
        sta pointerLo
        lda #>(welcome)
        sta pointerLo+1
        ldx #$00
        ldy #$00
WelcomeScreenOutsideLoop:
      
WelcomeScreenInsideLoop:
        lda (pointerLo), y
        sta $2007
        iny
        cpy #$00
        bne WelcomeScreenInsideLoop
        inc pointerHi
        inx
        cpx #$04
        bne WelcomeScreenOutsideLoop

welcome:
        .incbin "welcome.nam"

I have a background files *nam Welcome and Game over.
Help me to place them correctly.

[Sogona]

The main loop should come before but yes, everything else should come after NMI since they're all subroutines.

I don't see anything with your nametable code that wouldn't make it work. Where are you putting it now?