popmilo

Thanks for playing the game ! Even in it's raw, demo version Work on the full game is going on well, it's almost 100% done, you'll get a chance to play it soon

You reminded me of a small tool I've coded and used years ago charmap-extractor-XP32.zip Shows how many different chars would be in each charset. You could use it to compare with your tool

Hmmm... Not a bad idea with inc/dec... Would need to go through vertical column that's leaving the screen, dec each char counter, then go through entering column and inc appropriate counters... Not bad at all @Wrathchild !

Linear, one way - yes. If you code it like that I've never done realtime "smart" virtual chars replacement, but I've seen people do it in demos etc. For example you can keep an 256 byte long array with tags for "is char on screen currently" and in this way know if charcode is free or not. Would need to be updated when you scroll in each new char column or row. Don't know now in 1minute of thinking about this how you could mark "char is no longer on screen" but I bet something can be figured out

What is it?! What is it?!

You're not scrolling, but you did turn on HSCROL in display list for each char row. That means you have take in account value of HSCROL register. Is it maybe zero ? Second question - is "missle_x" value of HPOS hardware register for player or missile ? ps. Send me xex file and I'll tell you exact formula for char vs pm pos.

As you've turned on horizontal scroll in each charline, you're screen char position will be influenced by value of hscroll register too. I'm usually using values for HSCROL in range between 12..15, that makes screen coords make sense the most When you turn on horizontal scroll, antic automatically fetches +8 chars then mode you're in. I assume you're using 40 char wide normal screen ? In that case Antic works like if it's in 48-wide mode. That means HSCROL value 0 will mean screen will be shifted entirely to the left side of 48 wide area. In 48 wide mode HPOS==$20 of pm gfx is aligned to left side of screen. So if you put value 12 into HSCROL register, screen will be shifted right 3 chars (3x4=12). That means that first visible char will be (SCREEN+1) Now, when you change HSCROLL to 13,14,15, parts of char at (SCREEN+0) will appear from left. You just have to experiment and see what suits you the best imho. Iterate and enjoy the process

i would say it's artistic freedom Each platform music was done by different person as much as I know. I like the Amiga version for example.

Nice idea with double pokey writes. I can do that. I'm in process of writing routines for playing fx, so will try to do stereo pokey at the same time.

As @Rybags said, you could have char data "brought in on the fly". In my experiments I did virtual charset thing with like a thousand different chars in "charset" for a huge level map (think 25x4 screens for example). I wrote python script to process map and write data for where which new char is supposed to be inserted into visible charsets as you scroll screen to the right. In the end number of updated chars per frame was like zero to four, five max. Of course I needed different kind of tilemap, and all those chars needed to be in ram, so I would say each approach takes it's own resources. Just do it you're own way I would sure like to see results

Well I hope that now I've really fixed that leftover pixels on bats bug One line of code was missing... I got help from guys on Atarionline.pl forum again, they pointed me in the right direction and an hour of debugging later, everything makes sense and I can not reproduce bug anymore. ps. I've added use of space bar/Start key at game over screen too. tony v9.xex tony v9.atr

Well you only have 8 chars left for "something else" per 3 char rows. With charset per char row, you have like 88 free chars per char row. For me 22 charsets is little too much That's why I've used 4 charsets which was gave me nice ratio of memory taken and free chars for soft sprites.

V8 - fixed leftover pixels on bats moving in complex paths. It was a different kind of bug then on Skulls, but not hard to fix, two lines of code tony v8.xex tony v8.atr

Yes there will be sfx and they sound great, just need to code routines for playing them

I use almost every possible part of memory now I needed that as I've packed title screen etc. Just story text is almost 4kb long... 64k is enough and works in most cases I've tested so far including my own 800xl with memory expansion. Anyway, we'll make final game work on as most machines as we can without need for memory expansions.

ps V7 is out Fixed clear pixels bug with skull sprite (maybe others too). Added small fade out/fade in color changes and made START key skip parts too. Enjoy!

Ok, I've tried with atari os a.rom and confirm it's not working... will investigate... Does it have to do something with 40kb large xex ?

Take any continuous part of ram imho. Turn of Os if leftover space is not enough. Ignore trying to preserve "important memory locations not supposed to be touched" Be a rebel! Use every possible byte to make 22 charsets work ! Make something unique... Then... When it's working and people are amazed - then and only then try to optimize, make it more compatible or whatever... Until then just take space from where you can

I've tested with Altirra 4.10, 4.20, 130xl, 320kb ram, altirra os mutliple variants, basic turned on and off, no issues. Make sure you're using latest version (from first post in this topic). There was important fix couple versions ago regarding loading. Good luck!

New version with fix for issue with dying forever when jumping over the edge of screen into death (on spikes). Thanks to people who discovered it and shared on Atarionline.pl ! Video of bug here: tony.mp4 New version v6: tony v6.xex tony v6.atr

"8Bitworkshop" got much much better recently, has huge choice of platforms to develop for, examples and built in emulator. And all that in a browser, so no install needed: https://8bitworkshop.com/v3.11.0/?platform=atari8-800&file=joyas.bas

No Will fix it Here's fixed sprite gfx for climbing on ladders. I've accidentally moved sprite frame single pixel to the right when I was copy-pasting new gfx into sprite sheet. tony v5.xex tony v5.atr

I like the idea for puzzles Means I'll have to make all new section of code and spend more memory, but hey it's for a good cause As I implement disk loading, larger levels can be split into multiple parts, or we can go cartridge route and make a 1-2 mb game if we like Gfx by @RafalDudek is just crazy good to not be in the public

First an update: V4 - fixed wrong info in file header that caused problems with loading. (Files available for download in the first post too). I forgot to update label for end of code when I was moving stuff around memory to fit title screen in. That caused problems for loading in some cases (emulators didn't mind that unfortunately). So, people with Sio2Pc and real Atari, please test this new xex and atr. Thank you! tony v4.xex tony v4.atr

Yeah it's a known bug, some stupid mismatch between memorizing old position of sprite and actual erasing it when new frame is drawn (or enemy is removed). Will fix it as soon as I can.