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

gauntman

Members
 View Profile  See their activity

  • Content Count

    91

  • Joined

  • Last visited

Posts posted by gauntman

  3. Posted · Edited by gauntman

    You are advancing $d1 to much -- in single resolution mode, Player 1 is 256 bytes away from Player 0 -- so, only increment $d1 once.

     

    actually, looking at the code, you could use direct storage instead of a zero page, something like this:

     

      ldx #0
 ldy vpos
drawLoop
 lda shape,x
 sta $8200,y
 lda shape2,x
 sta $8300,y
 inx
 iny
 cpy #10
 bne drawLoop

     

    You might want to flip your shape data, then you could decrement x instead of increment, saving a compare. But get stuff working first, optimizations can come later.

  5. Posted

    I really hate to drop NTSC support, since I am an NTSC user... I was always sad to see a cool game that I could not play on my own system back in the day. Of course, now most people probably can/do use emulators, but I still really would like to squeeze this into a game that I could have played back in 1986 on Christmas day!

     

    If worse comes to worse, I probably could double buffer and drop to 30 frames/sec - but that would require reworking a lot of logic code and the graphics system (the original UWOL worked at 25 frames/sec).

  6. Posted

    I am writing this in assembly, using the original C source as a guide. The actual game logic was not too hard to port - I am struggling right now with getting softsprites running quickly enough for NTSC. Currently, I am working on turning off the O/S to get more memory, which should allow me to unroll more code.

  9. Posted

    Hi all,

     

    Here is a utility that may come in useful when pulling together multiple RMT songs into a single file. I wrote this as part of the UWOL project, where we had 10 songs. Merging the RMT files can save space, particularly if the files utilize many of the same instruments. This saved around 500 bytes.

     

    Here is a snippet from the readme file:

     

    Basic Usage

    ===========

    First, load each of the RMT files you wish to merge into RMT, and then save as rmt .txt

    files ("TXT song files"). rmtmerge only works on rmt.txt formatted files, not on

    native rmt files. Once you have saved all of the files you intentend to merge, run

    the following command line:

     

    rmtmerge file1 file2 file3 file4

     

    This will load all the files on the command line, merge them, and save the result as

    merged.rmt.txt

     

    Next, load the merged.rmt.txt file in a text editor and remove any extraneous [MODULE]

    sections (there should only be one in a legal rmt.txt file).

     

    Finally, load the file in RMT, go to the Song menu, select "All size optimizations".

     

    Enjoy!

    rmtmergev10.zip

  13. Posted

    just skip the playback routine every 12th VBI when it's NTSC. I was surprised it works so well, but it seems you really don't notice any timing problems (well maybe some people with amazing hearing/musicality can!).

     

    Of course! I hadn't thought it would be that simple, I thought that the artifacts might be too noticable -- I will try at 1/12 and 1/6 and see if the music still sounds right. Otherwise, I will look at the more invasive suggestions from Rybags.

  14. Posted

    Hi all,

     

    Looking at the rmtplayer source code, I don't see anywhere that corrects for NTSC/PAL timings. How can I play a song at PAL speeds on an NTSC machine?

     

    Note: I want to be doing this during gameplay on a screen with pretty heavy DLI useage. Currently, I am calling the routine during the deferred VBI... moving to a busy loop watching VCOUNT is undesirable. How are other people doing this?

  15. Posted

    I recently needed RMT for a project I have been working on in ATasm. Attached is a port of RMT 1.28 for the ATasm assembler, in case someone else also finds this useful.

     

    From the readme.txt file:

     

    This is a quick-and-dirty port of RMT 1.28 to the ATasm cross-assembler. The original assembly code is by RASTER/C.P.U. Any errors in this version have probably been introduced on my part. This port has not been extensively tested yet - certainly not under all possible permutations, so there may still be some problems.

     

    The sfx demo from the RMT distribution has been also been converted to ATasm and is included as an example of how to use the source.

     

    One difference in usage compared to the XASM/MADs version is that ATasm will include the RMT binary directly instead of linking it. This requires the RMT executable header to be stripped. The header is simply the first 6 bytes of the file. Included is a very simple C program that does just that.

     

    This means that you will need to remember the address specified when exporting a song. Then, in the source do the following:

     

    *=$4000 ; or where ever the export was set

    .incbin "song.rmt.bin" ; a regular RMT export, with first 6

    ; bytes stripped off

     

    As a general rule of thumb, if the sound is not working, probably you forgot to strip the header from the RMT file.

    rmt128-atasm.zip

  16. Posted

    Just chiming in to give encouragement to Fandal. It would be easy to be disappointed due to the contest results... however, do not give up! Your contributions to the modern A8 scene are really appreciated. It is obvious that you and Raster put a lot of time and effort into these games. Both Milk&Nuts and Robix are good games in their current state, with a bit more polish they could become classics. Robix in particular is a lot of fun to play, particularly with two people. Back in the day, my brother and I would have stayed up many late nights playing this (although now it is a bit harder since we live in different parts of the country).

     

    I look forward to new games from you in the future.

  18. Posted

    There would be lots of trees and stuff in different positions. Let's say a chest and a tree and mountains and plains as well as the ocean on the outside is on one line. How could I have a golden chest, a tree with green branches, a blue ocean ... Wouldn't that be impossible?

     

    As long as you didn't have them on the same line on screen at the same time, you would be okay... i.e. if you are scrolling horizontally, you could have a chest initially. As soon as that has scrolled off the screen, you could then show the tree, etc. This can be a bit tricky to manage, though, and requires careful map design.

  19. Posted

    Agreed - for text, mode 2 is much easier to read. If you are blocking out the entire row, all the players and missiles should be available (unless you have a cursor, or different colored text backgrounds) - so some nice portraits should be possible, using DLIs + OR'd colors.

     

    If you use the GTIA trick to split the screen, you will need to use Antic F instead of 2. The idea here is to delay until the right side of the screen, then quickly switch in and out of a GTIA mode. This confuses Antic and the rest of the line ends up in an Antic E-like mode (although the palette is a bit different then usual).

  20. Posted

    Here's my take on the original code. Right now I'm attempting to move a character when the joystick is moved to the right. Instead it seems to jump several characters. Any ideas? And thanks so far for the further help!

     

    The code looks okay - my guess is that it is jumping because the code is executing several times before the screen refreshes. Moving by character steps is much faster in assembly than in Basic, so it is zipping 2-3 times before the screen can catch up. You will probably want to place the movement code (or at least the drawing) into the VBI - and most likely only execute every other frame or so. Alternatively, you could hook up to a timer or for now busy wait.

     

    i.e. for testing at the moment, just before the "jmp j1"

     

    j0   lda 20
    and #7
    bne j0  ; delay for 8 jiffies

     

    You may wish to change the 7 to a 3 for a faster response.

  21. Posted

    Hi Avram,

     

    The concept to wrap your head around when moving to assembly language, is that you are now in control - not the OS routines. So, while it is possible to call the OS graphics routines to set GR.12, it is more typical to set up the display list and screen memory yourself. Here is a small example... this actually is doing a lot more than necessary, including setting up look-up tables for plotting that is definitely overkill for this example, but might be useful for a larger project.

     

    	
*=$4000

begin	lda #<scr       ; start by calculating look-up tables
sta $d0	        ; at the same time, we will clear the
lda #>scr       ; screen
sta $d1

       ldx #0
c0	lda #0
ldy #39         ; clear a single line
c1	sta ($d0),y
dey
bpl c1

lda $d1         ; store address into look-up table
sta schi,x
lda $d0
sta sclo,x
clc		; update zero page to next line
adc #40		; 40 bytes per line
sta $d0
bcc c2
inc $d1
c2	inx             ; for all 24 lines...
cpx #24
bne c0

lda #4		; set some colors
sta 708		; make ANTIC4 slightly more readable
lda #6
sta 709
lda #8
sta 710

lda #<DLIST     ; finally, point ANTIC to new display
sta 560
lda #>DLIST
sta 561

; Plot a character
ldx #20		; vertical position
ldy #20		; horizontal position

lda sclo,x	; set up zero-page address
sta $d0
lda schi,x
sta $d1
lda #33		; plot the character
sta ($d0),y

; Plot a block
ldx #8		; upper corner
ldy #8
lda sclo,x	; set up zero-page addresses
sta $d0
lda schi,x
sta $d1
inx
lda sclo,x
sta $d2
lda schi,x
sta $d3

       lda #34		; plot the character block...
sta ($d0),y	; warning - no boundary testing
sta ($d2),y
iny
sta ($d0),y
sta ($d2),y

j1	jmp j1          ; wait

DLIST
.byte 112,112,112                        ; blank lines
.byte 68,<scr,>scr                       ; 24 lines of ANTIC 4
.byte 4,4,4,4,4,4,4,4,4,4,4,4,4,4,4
       .byte 4,4,4,4,4,4,4
.byte 65,<DLIST,>DLIST                   ; Jump to top

*=$5000
scr     .ds 40*24				 ; 960 bytes for screen

sclo    .ds 24
schi    .ds 24

     

    So, in this case, I created a display list for an Gr.12 screen, with screen data starting at the address scr ($5000). The book Atari Arcade Graphics and Design explains this pretty well in the early chapters, if you want more information.

  22. Posted

    The just-released-today version 1.07 of ATasm has a new experimental .BANKNUM operative that returns the bank number of a symbol. In addition, the .BANK directive has been extended to allow manual specification of actual and reported-by-banknum number. For instance in the following nonsense code:

     

            *=$4000
.bank
       lda #1
       sta 710
       jsr j2
j1      jmp j1

label2
       lda #77

       *=$4fff
       .byte $ff

.bank ,2 ; assemble into next bank, report as bank 2
       *=$4000
j2      lda #2
       sta 712
       rts

label3
       lda #77

       .byte .BANKNUM j1, .BANKNUM j2, .BANKNUM label3

       *=$4fff
       .byte $ff

.bank ,0 ; assemble into next bank to keep obj in source order, but report as bank 0
       *=$3000
j3      lda #64

       .byte .BANKNUM j3

     

    .BANKNUM j1 will report as 0

    .BANKNUM j2 will report as 2

    .BANKNUM label3 will report as 2

    .BANKNUM j3 will report as 0

     

    You can get the ATasm 1.07 release from the primary website or from the trunk of the sourceforge svn server. If the new features look solid, then the sourceforge site will also be updated with binaries and tags. Hopefully this new feature will prove to be useful.

  23. Posted · Edited by gauntman

    BTW, there are other line drawing routines that could be used. Two-step is supposed to be faster. I just question whether the limited number of registers on the 6502 will allow any speed increase since the faster ones draw from both ends of the line.

    If you use the lookup table as suggested... maybe. It could be similar to unrolling the loop part way if you don't have to do much register swapping.

     

    The double-step algorithm could be interesting, because it plots the next two pixels on the line, which may reduce shifting masks. Most versions of this I have seen plot the line from both sides and draw to the center of the line (see for instance: here). This might eat up too much of the ZP on the 6502 - but drawing from a single side may still be a win.

  25. Posted

    Are there settings for the pmg that allow a pixel of pmg to be the same size as a pixel of one ( or both ) of these resolutions?

     

    In addition to the horizontal size mentioned above, the vertical resolution of the PM can also be changed to either single or double. Single resolution is one scanline high, while double is two.

     

    To match a pixel in Gr. 7, use double vertical resolution

    To match a pixel in Gr. 15, use single vertical resolution.

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...