Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

vidak

Members
 View Profile  See their activity

  • Content Count

    499

  • Joined

  • Last visited

Posts posted by vidak

  2. Posted

    The StayFrosty blog posts from SpiceWare are also really useful for teaching you masking.

     

    My project codenamed Sierra Maestra copied the masking concept from StayFrosty, and has a much simpler implementation of it, currently.

    Using ROM as a mask is much much faster, and I highly recommend it.

     

    The SkipDraw, FlipDraw, DoDraw and SwitchDraw routines are all many times slower than masking.

    • Like 1

  8. Posted

    Hm... A release full of new features results into discussing folders only.

     

    That definitely makes me wonder... :ponder:

     

    I think I may finally have work in the next week or so - so I'll definitely donate some money soon.

     

    The work you're doing is really important, and deserves recognition.

    • Like 1

  9. Posted

    Thanks so much for your responses!

     

    Another idea I'm having is to develop some reuseable routines for people to easily copy to allow them to make games in ASM more easily.

     

    The multi-band kernel I have is very easily copied and used, and I think copying and manipulating gauauu's multi-screen overworld could also be presented in a simple way.

     

    I will certainly ask questions when I feel stuck!

     

    I agree that the graphics ROM and the kernel should be in the same bank - I think that's the fastest way. In fact I think that's the only way you can structure the bank switching - any other way would be incredibly and possibly prohibitively complex...

     

    Do you think it is worth me explaining how the multi-screen overworld is implemented in Anguna? If so, would it be better do it in this thread, or on my AtariAge blog?

     

    I wonder if I'm forgetting anything...

     

    ===

     

    Anyway, I love how naughty ASM is. It has absolutely no enforced typing whatsoever, so you can, as in Yar's Revenge, make a pointer load /any/ part of the ROM for /any/ purpose. All the naughty tricks that you're able to pull off with the 2600 completely depend on the fact that you almost always program in ASM. It's such a wonderful platform - the hardware is so adaptable and really wants to help you. HMOVE rules can be broken with useful results, etc etc

    I knew I really liked the 2600... coming to know it more intimately gives me a lot of satisfaction and fulfillment.

    • Like 1

  10. Posted

    Okay! I am dedicating some time to the project today.

     

    The next thing I'd like to achieve in the development of the game is to create an overworld map, and have the character Che be able to move around in it. I have been looking at the source code of Anguna (link) to have some idea about how I'd be able to achieve this. Anguna has a 13x13 unit square overworld, and you are able to move from one screen to another.

     

    The rough idea behind implementing an overworld is that you have a table of data describing what the overworld is like, and as your main player character moves off one side of the screen, you manipulate a counter or a pointer so that it points to a different part of the overworld table. I think I can handle this.

     

    I think I will not have enough space in 4KB in order to implement an overworld and the main game mechanic. I will expand the game to 16KB. I think F6 bankswitching will allow me to achieve this. This is how gauauu structures his 4 banks:

     

    BANK 0 - Main Loop Logic, "Preparation" Macros - I assume this is for updating graphics pointers etc.

    BANK 1 - main kernel, header graphics kernel, some code related to the third boss, and the graphics ROM

    BANK 2 - Header pointer preparation logic and game logic crammed in between the spaces

    BANK 3 - password entry, and room background graphics preparation

    ram

     

    I take it that the banks are structured in such a way as to best fit all the data in, not necessarily for easily interpreting the structure of the game program.

     

    I have begun learning the programming language Ada for another project I want to work on, and the way gauauu has structured their code into smaller packages agrees with the way coding is meant to be done in Ada. So far I have been compiling a rather large single file. I think I will begin to break my program up into smaller files and make much more use of macros in order to reduce the amount of engineering I have to do. Making the tools do the work is the way Ada pictures the overall development process of software engineering. I will use this philosophy here on out while programming the Sierra Maestra project.

     

    For the next few weeks I will begin a description/explanation of how Anguna implements a multi-screen world that you are able to move through. The licence that gauauu has provided the Anguna source under allows me to do this.

  18. Posted

    You should check out the Spectre and Meltdown vulnerabilities in all the Intel CPUs since 2006 - hardware and CPUs are just as vulnerable to security exploits as software. The way Intel CPUs have been botched in their construction allows you to hack them at a very low level and get complete control of them.

     

    I agree about clock speeds. The way forward is RISC. We have many cores but very little industry effort put into parallel processing.

     

    Anyway this is getting off topic isn't it... My fault!

     

    Personally I think the PC metaphor is terrible, and the Microsoft/Intel/Apple monopoly is ruining everything hahahab

  19. Posted

    I was born in 1991 - my dad had always used Intel and IBM together. He had an IBM PC with a 8088.

     

    Personally I find the x86 Intel platform ugly and unparsimonious. The design philosophies of the Ataris and the Amigas were much more beautiful.

     

    The reason why we have enormous critical failure points and security weaknesses in Intel CPUs goes right back to the design concepts Intel used in the 70s.

     

    I wish the 68000 had become the ancestor of our CPU hardware because it was a very beautiful design.

     

    I have always hated PCs despite their fame and wide use. The reason they are widely used is not because they're any better but because the effort of training yourself to use a different system is too high.

     

    Microsoft and Apple both rely on the affective familiarity people have with their systems.

     

    Personally, I would like to see more hardware diversity, less monopoly, and more cooperation.

  20. Posted

    OKAY FIXED.

     

    What I am uploading here is the final version for this stage of the game's development!

     

    What I still need to do is:

     

    - Create a network of screens for Che to move through.

    - Create the logic for the movement through this world: (i.e. when Che moves off the left side of the screen, he appears on the right side of the next screen to the left of that screen)

    - Create movement routines for the peasants and the batista soldiers, maybe simple AI to this effect

    - Create graphics for the peasants and the soldiers

    - Create graphics for the jungle environment

    - Perhaps add more tasks for the kernel, seeing as I am only using 43-44 cycles for the entire kernel. This is only 58% of the maximum cycles needed for the kernel. So I think I may add in playfield graphics.

     

    THEN

     

    - Create the kernel and logic for the "Lock and Load" portion of the game, after I have completed the above portion of the game, the Overwold portion.

    Guerrilla32_bin_FINAL.zip

    coloured_guerrilla032.asm

    post-61331-0-69632200-1517635996_thumb.png

    • Like 2

  23. Posted

    Okay I have rejigged the kernel. It is now a lot faster, even though it doesn't allow GRP1 to touch the left side of the screen. The whole kernel takes 41 cycles now, instead of 53 cycles.

     

    I am loading the colour table for GRP1 synchronously with the graphics, and this fixes the indexing issues for the colour of GRP1. PROBLEM ONE IS SOLVED.

     

    Here is another improvement: now the colour table for GRP0 is CONSISTENTLY off by one line. This means there must be a static indexing issue.

     

    To the Stella Debugger to see what the problem is!

    post-61331-0-90770900-1517630766_thumb.png

    coloured_guerrilla029.asm

  24. Posted · Edited by vidak

    Okay changing the temporary enemy graphics colour table from this:

    BatistaSoldierClr
    ds 15, $00

    .byte $FE
    .byte $FE
    .byte $FE
    .byte $FE
    .byte $FE
    .byte $FE
    .byte $FE
    .byte $FE
    .byte $FE
    .byte $FE
    .byte $FE
    .byte $FE
    .byte $FE
    .byte $FE
    .byte $FE
    .byte $FE
    .byte $FE
    .byte $FE
    .byte $FE
    .byte $FE
    .byte $FE
    .byte $FE
    .byte $FE     <- 23 bytes of $FE

    To this:

    BatistaSoldierClr
    ds 14, $00

    .byte $FE
    .byte $FE
    .byte $FE
    .byte $FE
    .byte $FE
    .byte $FE
    .byte $FE
    .byte $FE
    .byte $FE
    .byte $FE
    .byte $FE
    .byte $FE
    .byte $FE
    .byte $FE
    .byte $FE
    .byte $FE
    .byte $FE
    .byte $FE
    .byte $FE
    .byte $FE
    .byte $FE
    .byte $FE
    .byte $FE
    .byte $FE   <- 24 bytes of $FE

    Fixes the issue. Which leads me to believe that I am right about COLUP1 being written to out of sync.

    So instead of doing this in the kernel:

    .KernelLoop

     sta WSYNC

     lda CheGfxTemp
     sta GRP0
     lda EnvGfxTemp
     sta GRP1

<kernel code>
     ...
     sta COLUP1

     ...

     dec SCANLINE_COUNTER
     bne .KernelLoop

    I think I will have to do this:

    .KernelLoop

     sta WSYNC

     lda CheGfxTemp
     sta GRP0
     lda EnvGfxTemp
     sta GRP1
     lda EnvClrTemp
     sta COLUP1


<kernel code>
     ...
     sta EnvClrTemp

     ...

     dec SCANLINE_COUNTER
     bne .KernelLoop

    I think this will fix the sync issue, at the cost of a less efficient kernel.

    coloured_guerrilla028.asm

    post-61331-0-10695500-1517627162_thumb.png

  25. Posted

    Alright it's the weekend here in Sydney, so I have time to work on the game!

    I will do a live-update debugging for anyone who is interested. I find this method of debugging is the best for me because I can track EXACTLY what I did after every compile.

     

    I have fixed the colouring problem of the enemy characters by manually copying over the graphics pointers from EnvGfxPtr and EnvClrPtr:

        lda EnvGfxPtr
    sta EnvGfxPtr+2
    sta EnvGfxPtr+4
    sta EnvGfxPtr+6
    sta EnvGfxPtr+8
    
    lda EnvGfxPtr+1
    sta EnvGfxPtr+3
    sta EnvGfxPtr+5
    sta EnvGfxPtr+7
    sta EnvGfxPtr+9
    
    lda EnvClrPtr
    sta EnvClrPtr+2
    sta EnvClrPtr+4
    sta EnvClrPtr+6
    sta EnvClrPtr+8
    
    lda EnvClrPtr+1
    sta EnvClrPtr+3
    sta EnvClrPtr+5
    sta EnvClrPtr+7
    sta EnvClrPtr+9

    I can identify two problems:

     

    Number One

     

    The colour of Che seems to shear on the right side of the screen. The graphics shape of GRP0 is correct, but the graphics seem to be applied one line BEFORE they're supposed to on the right side of the screen. I will use the Stella Debugger to have a look at this.

     

    Number Two

     

    This is very confusing. The last line of the GRP1 graphics loads properly, but seems to have the colour $00 applied to it, instead of $FE, like it is supposed to. I checked the Stella debugger, and the colour that is being loaded is definitely $FE, which is bright yellow, but it seems to show up as black. This is very confusing.

     

    My best guess for why this is happening is that I am setting COLUP1 earlier on in the kernel before i WSYNC lower down in the kernel, and then I am drawing GRP1 right after the WSYNC at the top of the kernel. I thought these two TIA register writes were in sync, but maybe the colour for GRP1 is being written again after I have drawn it.

    As always, if there are any people reading this before I update again, feel free to jump in and give your opinions.

    coloured_guerrilla027.asm

    guerilla27 bin.zip

    post-61331-0-33181000-1517626411_thumb.png

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...