analmux

Well here's another production of mine. You guessed it right, it's mario again. These are screenshots from some of my levels in debug-mode (no sprites/no playing). The main idea, graphics and all levels originate from 1995-1998. Then I finished highschool, started studying, but now I'm ready to finish the coding. The game will be available as freeware soon (possibly this year). It's still Antic 4 with flickering sprites, but I think it's a nice start for a beginner. It uses in fact almost the same spriteshapes from the SMPDEMO. -mux

Is this what you mean? ..well, this is kind of weird too.

Well I don't see much use of PM multiplexing. With DMA on, only ONE Pmbase (--you want to change the PM-shapes I suppose--) is usable each scanline. With DMA off, you need too many cycles to make it look good. Don't forget that in coarse PM you must reload the data of the first PM's on the left of the screen every other scanline....Great for static pictures, but horizontal colour-changing kernels are VERY time consuming, or you should make halfscreen games or something. I'm not sure, but it should be possible to mix colors with PM in GTIA 9 (only PM 0 & 1 I'm afraid) ---------------------- But I've done some stuff in the 90's too. I've made a simple turbobasic mario (which I never finished). You may download SMPDEMO.ATR (using turbobasic, which you can find on hscroll2.atr) and type: run "d:smpdemo.bat" run You can enter a levelnumber between 0 and 15 and play. It's rather slow, has a few bugs too (mario can't face left, etc.), but it's an idea of what my new game will look like, but the new game will off course contain many PM overlays, better colorbalance, smartfonts, dynamic sounds, multilayer SCROLLING !!! (Hor. + Vert.), Machine Code instead of basic, and a big choice of levels. I think (I hope) I just found the right balance between quality and speed. there is another turbobasic program on the same ATR, which just shows a titlescreen of Mario3. Just type: run "d:mariotit.bat" run --Enjoy the stuff-- analmux

I tried different DLI routines based on this idea, but nothing happens?! ----- I have some digicam pic's of the antic hscroll bug from my real atari screen. In 2.jpg you can see the weird Player DMA which shows a piece of character $7F. In 3.jpg you can see off course normal gr.0 lines, but in the upper part you could, if you look hard enough, read "10 graphics 0:.." where it seems that the fonts are overlapping a few pixels. In 4.jpg you can see text with a different custom made font that's 4 * 8 pixels per character, and it helps to see that it's a kind of 80 column mode, in which antic reads about 48 screendata bytes. 5.jpg is just a global view, but no details are visible (I only have a 300*200 cam). I have made another version of hscroll1.tbb. It should be loaded with: run "d:hscroll2.bat" run in this version the custom 4*8 font is used, with high contrast setcolors. ------- analmux

Silly me! I forgot the 9 D-RAM refresh cycles on almost every scanline, performed by ANTIC on horizontal (PM) positions 16,24,32,40,48,56,64,72 and 80. -9 * 262 = 2358 result: 23517 It's worse than I thought.

I think you could better use PM 3/4 for filtering colors, because this allows for a partial shine-through. Playfield Color 0 & 1 clip PM color 2 & 3, so they are only usable as large solid blocks.

Not when you program a game. Even smarter would be a PM-data change only on 16-scanline intervals using the same DLI I described before, by setting GTIA DMA off (poke 53277,0) and writing the PM-data in the direct PM-shape bytes ($D00D -- $D010). This saves a lot of CPU time you otherwise would need to literally move the shape-data around in the PM-base, also PM DMA is off, which saves another 1152 cycles (but you would need the extra cycles for the extended D.L.Interrupt) ---------------- analmux

That's right Emkay. Scrolling the main layer is just a matter of changing the startadress of screenmem in a DLIST. No double buffering needed. So the main task of the graphics-engine is updating exceptional character-zones, which results in simply changing charactercodes in screenmem. Even the enemy-sprites could be implemented very simply by just using fonts for the phases of movement an enemy makes (usualy up/down or left/right only). Only a realtime software sprite handler would be needed for the player-sprite which (in most games) can not be restricted to one-directional movement. Just realise that you won't need more than, say, 384 characters in a whole screen, and let the smartfont system update fontdata only when moving an entire screen further. ---------------- greetings analmux

That sounds very new to me. How is it done? As far as I know the C64 can't change the starting adress of the screenmap under 1 kB-precision. And what does 'double buffering' mean?

Ok let's calculate the amount of available CPU cycles on the Atari. 1789790 cycles/second: 35795 cycles/frame (50 fps Europe!! 60 fps is worse) -8640 cycles/frame DMA Antic mode 4 (40 * 24 * (8+1) reads) screen and fontdata -1280 cycles/frame DMA Players & Missiles (Hi-res) 25875 cycles/frame remaining for the CPU, which could be used for about 2700 LDA a,x - STA a,x instructions. Roughly speaking, you can easily change the data of 256 characters, including software sprites Note that the C64 must move its whole screen for a simple scroller: 2000 bytes (screen + color RAM). Although this is not always necessary every frame (especially with slow fine scrolling), this is used in games like Turrican II: Just watch the amazing fastscroll in level 3-3, with multilevel scrolling tiles for pseudo-3D. The first time I saw this my mouth fell open. But now I remember, there wasn't too much color in that level, so it could even hold color-Ram static on the whole screen or at least in certain areas of the screen. About memory-usage: Think about how Turrican II handles this problem: levels of 16 KB on a floppy. It uses 8 KB for the leveldata only (1 byte for each 4*4 charactercluster) and additional data for enemy positioning, enemy-movement tables and the fonts and numerous sprites, which are all different in each world. (Yes, I've never seen a better game on the 8bits) About color-usage: Graphics with PM overlay and Prior=0 should be treated very carefully. Only PM0/1 overlays with PF0/1 and PM2/3 with PF2/3 BUT the main problem is that PM0/1 also CLIPS PF2/3 which results in a decrease of colors in that region. But with some clever design I think you could make graphics like SONIC 2 on Atari. Most of the graphics (though not the same high resolution) of Super Mario 2 & 3 is possible on atari, in combination with PM-overlay and Prior=4 (PM shines through at BG). I'm working on images of SONIC 2 and SMB2/3. Prior Number of overlay colors 0 11 4 9 32 21 36 15 Off course you could write a whole game in TIP textmode graphics 0 (other modes decrease GTIA 11 colordepth). With even digital sound sampled by the DLI's needed for TIP. But I think that configuration is more useful for demos. But there is hope: We could construct the screen like this, in most platformgames: -24 lines Antic 4 -Every two lines a DLI that changes the characterset, the 9 colorregisters, PM positions and refreshes Pokey's soundregisters for creating pseudo-complex effects and music. -12 fonts that are the same for tiles and blocks that are used very often (such as the ?-blocks from Mario games), and don't change frequently, but the remaining characters of each font can be used for software sprites (multiple shift-phases) and characters from a different layer that scrolls at a different speed. Also precalculated characters. You could use a shift table that contains the 2 and more times ASL/ROL/LSR/ROR-ed bytes for fast software sprites. -A VBI to smooth scroll and trigger the screendata-changes, and also to move the (course resolution) PM data for vertical scrolling. Note: You don't have to move PM data EVERY frame when using Prior 4 overlay (shine-through) In this way you can divide a level in zones with different graphics and colors, by letting a smart background program update the fonts (i..e.) every 50th frame, or every time you move precisely one screen to the left or right, when the screendata needs a little treatment. And you can reserve lots of characters for exceptional events when for example a software sprite overlaps a bit of background, all precalculated in the so-called refresh-frame (every 50th frame). This might be a technical difficulty but with clever design it should be possible. I am working on the principles of this so called 'smartfont' screenmanaging, and I am planning to use this idea in a game, similar to Super Mario 2 & 3 and Sonic 2, that I am planning to write, for which I will write a demo with some of the game situations first. --------------- analmux

I will try to make some digicam pictures tomorrow, I'm going to bed now, Have to study etc.

I think it is possible to create an atari game with graphics in TIP-mode. There is a trick to show TIP graphics in textmode 0 with 64 colors. You could add Flickering/interlace if wanted. I made a little Turbobasic program that shows TIP in gr.0 Just boot the ATR. Load "turbobas.sys" and load "gtia64.tbb" ....... Another thing: I don't know if it's already discovered, but I think I found an Antic-bug which occurs when you change the HSCROL addres $D404 while ANTIC does a HBLANK. Try my program "hscroll1.tbb" (on the same atr) to see. It seems that you could create a 80 column textmode. Watch the weird Player-DMA on the right. It shows that Antic-timing is messed up. It reads characterdata in the time that it should read PM data, and it even reads displaylist-data in the time that it should read characterdata. See what happens when you fill the screen with text (type "list" for example) and then type "goto 300" to scroll a bit. Weird isn't it?? (you should off course run the program on a real machine ) Greetings Analmux