gauntman

There was a fairly in-depth discussion of this recently. This thread might provide what you are looking for: http://www.atariage.com/forums/topic/107853-need-the-256-colors/page__st__25

NTSC will not blend the two colors together. I don't have my machine set up at the moment, but this was the problem with APAC and other similar techniques that used alternating colors. It almost works, if you squint -- but the lines are definitely distinct. Perhaps someone can confirm this with a screen shot. Actually, I would be curious to see a PAL screen shot of this as well. (Edited to include PAL screenshot request)

The problem here is that the levels are generated randomly (along with the secrets) so I do not know in advance what the maximum number will be for a level. One time it might be 26, the next time 38, and so on... in this case a hard-coded look-up table won't work (or at least, could get very big). Maybe storing the reciprocal in a look-up table for each possible maximum, then using that in an adding loop? i.e. 1/2,1/3,1/4 ... 1/50 Of course, that probably the reciprocal probably requires 2 bytes in order to prevent too much round-off error....

Someone posted a question about bit twiddling in one of the 6502.org forums that was part of the answer some interesting stuff there (one of the interesting things is a pointer in one of the forums to this forum ) I believe I saw that posted to comp.sys.cbm some years ago, don't remember where it was said to have come from. Don't you need a clc in there? I think I have seen this as: sed cmp #$a adc #$30 cld

In the spirit of the Fast Divide by Seven thread... and not to derail that one too much, here is another similar puzzle. Instead of displaying a number of secrets discovered as 2/12 or 8/19 or whatever, I would like to display a percentage. I know in advance that the number of secrets to discover will be less than 50, and the minimum number found is 1. The obvious way to calculate this is simply: n*100/t Where n is number found, t is total items. Here is some code that does exactly that: acc = $c0 aux = $c2 ;================================================================== ; GetPercent ; A = items found (1<=A<=X) ; X = total items (1<=X<=50) ; returns percentage in A ; ; uses a,x,y,4 zp variables (acc,aux) ; between 362-397 cycles; avg 377 ; ;================================================================== GetPercent ; Calculate a*100 -> acc (73 cycles) ldy #0 sty acc+1 sta acc asl a ; *2 asl a ; *4 adc acc ; *5 ... max 250 asl a rol acc+1 ; *10 asl a rol acc+1 ; *20 sta aux ldy acc+1 sty aux+1 asl a rol acc+1 ; *40 asl a rol acc+1 ; *80 adc aux sta acc lda acc+1 adc aux+1 sta acc+1 ; *100 ; Now perform acc/x -> acc, throw away remainder stx aux ; unroll 16/8 divide loop a bit, exploiting ; the fact that acc<=5000 asl acc rol acc+1 asl acc rol acc+1 asl acc rol acc+1 lda #0 ldx #3 div0 asl acc rol acc+1 rol a asl acc rol acc+1 rol a dex bne div0 ldx #7 div1 asl acc rol acc+1 rol a cmp aux bcc div2 sbc aux inc acc div2 dex bne div1 lda acc rts This isn't too bad, taking on average 377 cycles to calculate (assuming acc and aux are zero page) Does anyone have any other, more clever, methods?

Depending on the magnitude of the X and Y velocities, the fastest method is probably a look-up table. For instance, if your velocity is +/-7 in each direction, you can simply shift one of the axis 4 bits, and OR the other vector. Then use a 256 byte (precalculated) look-up table. lda dx asl a asl a asl a asl a ora dy tax lda angle,x Note: It should be possible to still use a 256 byte look-up table with velocities up to 15, taking advantage of reflection.

I have used Subversion for several years on many projects, and have been quite happy. However, recently I have been playing with the (rather unfortunately named) source control program called git. This works fantastically well if you are running a Linux box, but I don't think there is a very functional port for windows, yet. Git is the source control program written by Linus used by the Linux kernel crew. It has the advantage of retaining your history on your local machine, even when you are not connected to your main server. I have been using git recently, along with git-svn which allows me to synchronize with a subversion server (so I can still work with my less enlightened colleagues). Linus talks about the advantages of git at a talk at google, which can be viewed on youtube at: The git homepage can be found here: http://git.or.cz/

(see my reply about the AtariWiki above) is it "ok" if I put some of the content of this document in the AtariWiki? Of course you're welcome to take any content from the AtariWiki into the Ironman Atari document if it fits. So both, the Wiki and the Document can be updated. Carsten Hi Carsten, Posting content from Ironman on AtariWiki is fine. I was thinking about setting up a wiki myself, but there is no need for competing sites diluting the information. The wiki site could serve as an excellent place for the community to submit and refine articles between IronMan updates. There has been a lot of good feedback from this thread so far, and I am incorporating a lot of it into the next revision. I expect to have another revision by end of May. Rybags, have you confirmed on real hardware that when there is conflicting priority with PM/PF the overlap area will turn black (even against a PF0 of a different color)? ...Embarrassingly enough, my 130XE is in storage at the moment!

A few years ago, I started collecting interesting information and low-level programming information on "Lesser-documented" Atari features. Based on some recent threads (for instance, then HIP/TIP pages disappearing, etc.), it sounds like some of the newly won Atari information is in danger of being lost. I have decided it is time to release the current document version of my "Ironman Atari" document. This document is by no means finished -- or even up-to-date. The bulk of this was written back in 2003-2004 over Christmas. Some of the document has aged well, other parts less so. For instance, I have a place-holder in there for MCS techniques, and only a footnote for G2F. I have, over time, double checked the http links, and updated them as necessary, but other than that the bulk of the document has remained unchanged for almost three years. Putting together a document like this should be a community effort. I have considered hosting this in a wiki. but would like to have a more formal (and printable/bindable) product at the end. If you would like to correct items, write working source code examples, add new articles, please do so! Don't worry too much about grammar or spelling, I can clean that up as necessary. (Ideally, source code should compile with ATasm, but this is not truly necessary). If you are submitting an article for consideration, I would prefer it be in either OpenOffice format, RTF or raw ASCII, just to increase the speed with which I can incorporate the articles. Just add them to this thread, or PM me. I would like to restrict topics to items that are not covered elsewhere (i.e. I don't consider this a replacement for something like De Re Atari). Note: there are several places where there are "notes to self" in the text, these will someday be expanded into real articles, be updated or removed. In any case, if I wait until it is "done", this probably will never get released. So, here it is in a (very) rough state. I would like to have version 1.0.0 of Ironman Atari out by the end of the year. In the meantime, consider this a preview, and enjoy. age.pdf

It has been a long time since I have thought about the ST -- but here is what I remember. There were 3 main graphics modes: 1) Monochrome (only worked if you had a monochrome monitor, if I remember correctly) 2) 4-color mode "Medium Rez" (640x200?) 3) 16-color mode (320x200) Pretty much all games and applications ran in the 16 color 320x200 mode; In 16 color mode, you could choose from a palette of 512 different colors -- unless you were lucky enough to get an STE, in which case you were able to select from 4096. There were some tricks you could pull (for instance, Spectrum 512, an art program from Antic mag did this) that increased the number of colors on screen at a time -- but due to the processing power required, you really couldn't do anything aside from a static picture. "Sprites" use the same color palette as the main screen (the ST didn't really have separate sprites, everything was done in software -- again, unless you had the STE and a "blitter chip" -- but this only sped up the copying of memory -- it didn't increase the number of available colors on screen)

The answer is: yes. A wide playfield will always have the same number of color clocks -- however, older television sets used to "hide" or "crop" the edges. (For instance, on one TV I used growing up, I could not see characters in column 0 on a normal Graphics 0 screen. I could slide the picture with knobs on the back, but then I would lose the right margin). Depending on the television set, different amounts of the edges were visible. Modern CRT televisions usually will show the entire width without problem, and obviously LCD televisions, video capture cards and emulators also have no problems. In fact, in some older games you can see garbage along the sides where the programmer assumed clipping would take place (particularly in wide screen scrolling games) I am sure someone else can talk more about the "NTSC safe-zone" and the history behind it.

One problem I have with the high resolution graphics games, is with artifacting. Artifacting can be used for extra colors (ala Droll), but if you use source graphics that were not designed with artifacting in mind, it looks very distracting to me. Is artifacting not as bad in PAL? Or do we assume that everyone these days is running in an emulator/on a monitor?

Yes, witcher has realtime combat. The way it works, is you approach a monster -- clicking with the mouse button starts the attack. The attack animation begins, and at a certain point in the animation, the sword lights up. This is an indication it is time to click again, if you successfully click during the "window" of opportunity, then the attack continues. If you click too quickly, or too late, the chain is broken, and you need to start the attack again. I will see if I can cobble enough source together to post a running example.

Looking good! A few comments: 1) It is hard to tell when you actually hit a monster (although the sound is nice) - perhaps it might be good to lift a page from Gateway to Apshai, and flash background (red if you are hit, green when you hit something else?); Alternatively, some sort of swish sound to indicate a miss could help cue the player that they are in the wrong spot. 2) I have been working on and off on a similar type game (or more accurately, several pieces of a similar game, someday they may get all stitched together) -- To indicate the monster currently being attacked, I am using a symbol above the monster's head (like the exclamation point above the player's head); A simple dot, circle, or crossed sword icon might work. I am actually using a life bar, but may change this at a future point. 3) I am also using a technique that the PC game "The Witcher" popularized -- rhythm, combo attacks. So, the first attack opens a combo, then the player watches the color of the select icon, when the color changes, then it is time to attack again. Up to 3 attacks + "finish move" can be chained this way, each more powerful than the last. If the player attacks too soon or too late, the combo is broken and restarts. The time between the attacks is slightly random, as is the length of the window of opportunity. These times could be modified by the skill system. (Strength to change the length between chained blows, Dex to increase the window, perhaps?)

I have watched that project on and off. It has some interesting ideas, and very nice pixel artist(s). BTW, 256 characters are definitely useful for cacheing soft-sprites. I think in one of the blogs, a discussion of the cache system is made. It would be interesting to see if an ANTIC e version could be made. (Perhaps with MWP scrolling? This could help minimize the background drawing, but double buffering would be trickier).

I know that S.A.M. worked on the Atari 800 and the 130XE. I wrote a program ages ago for entering long ML programs that would echo back the number you typed in using the keypad, and I am sure I used it on both machines.

Didn't the game AirBall have similar screen layout? It has been long enough, I don't remember if they had masking, but I definitely remember wandering through isometric rooms 1 screen at a time.

I think the wired XBox360 GuitarHero controllers are standard USB -- so depending on the state of the USB project, "it might just work."

I use Atari800 -- but then again, I usually use Linux, so Atari800Win is not much of an option...

So... how do you get past stage 3-2 in CrownLand? (trying to avoid posting spoilers in the question...)

SQZ looks interesting, but it seems to be a packer/unpacker for entire programs(?). It does seem to implement not just Huffman encoding but also (less optimal) Shannon-Fano encoding. I wrote my Huffman encoder for streaming short strings out of memory onto the screen. Of course, SQZ may be able to do this already, but my Polish consists mostly of online translation websites - which provide very unreliable results!

As part of a project I am working on, I wrote a simple Huffman Tree text decoder. This consists of 2 parts: a C++ program that encodes strings, and a 6502 decoder that decodes strings. The C++ program analyzes an input string table, and generates a a fixed Huffman tree plus the encoded strings. The 6502 code decodes this, and prints the result. Encoding produces compression rates that range anywhere from 50-75% of the original string table size. Although this is not fantastic compression (compared to Huffman + LZH or LZW), it still doubles as light encryption, and it is a fast, memory light decoder. The zip file includes 4 files: textenc.cpp - the C++ encoding code (if you are on Linux/Mac compile with "g++ textenc.cpp -o textenc" for Windows, use mingw or other compiler) decode.asm - the decode routine + simple display and print routine for testing strings.asm - an example string table generated by textenc on jeeves.txt jeeves.txt - the string table used to generate strings.asm decode.xex - the example Atari executable Note that currently, the encoding is limited to text only (characters 0-125), and automatically performs ASCII to Atari internal screen byte conversion on the strings. Depending on your purpose, make sure that the tree + decompression code + compressed data is not actually larger than the original text! The break-even point for me was around 0.5-1k of original text. If you end up using this for anything, let me know! huffman.zip

Set your PRIOR to 0 (well, with the appropriate GTIA bits as well). I think only the missiles will blend though. I am pretty sure I actually tried this on the real hardware.

I would use bounding boxes. Particularly with a small number of sprites, this should be fast enough. I think there have been a number of discussions here about this. One good on is here: http://www.atariage.com/forums/index.php?showtopic=64287 I think there was on in the 6502 killer hacks thread. Hmmmm.... here: http://www.atariage.com/forums/index.php?s...st&p=873438 It is not pixel perfect collision, but more than enough for avoiding overlap.

I was thinking about this a bit over the weekend. There are a few shortcuts I can make in the project I am working on, and perhaps you can make some of the same assumptions: The important bit is the following: Overlap is only between sprites, no background/sprite overlap. I was surprised by this, but after tweaking my character set a bit, I realized that picking up objects, running into walls, etc. could be modified to always be character boundaries. The entire map could be reduced to impassible (filled chars) or passable (blank) This basic assumption leads to a few interesting optimizations: If the player is updated every frame (and always drawn first), you do not need to perform any masking or eor'ing of data, the player data can be copied straight across - if this does not completely hold, the first sprite drawn each frame can be handled this way. It might be worth making the player character always first, since then you can hardcode the destination address. Sprite/Sprite interaction - if sprites cannot visually overlap, then you can remove the masking of each frame. The only needed operation is the eor (or ora); Finally: Mostly sprites will be drawn over blank characters. When this happens, no eor/mask or background character copy is required. It is probably worth checking this case, assuming overhead of the test is low enough. Even if you are planning on allowing background or visual sprite overlap, the common case will tend to be no overlap (well as long as you have a consistent single character background - preferably blank) . This makes it more important to figure out a good way to perform the check cheaply.