Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


popmilo last won the day on October 23 2016

popmilo had the most liked content!

Community Reputation

1,393 Excellent

1 Follower

About popmilo

  • Rank
  • Birthday 11/01/1973

Contact / Social Media

Profile Information

  • Gender
  • Location
    Senta, Srbija
  • Interests
    Atari, Commodore, Spectrum, Amstrad and all other retro stuff...
  • Currently Playing

Recent Profile Visitors

20,046 profile views
  1. That's a very good question. I've just ordered some 3d printed cases for some c64 hw project my friend is making. In local print shop it comes out as 4 eur/piece. It's not perfect quality, and price is not 1-2 $ but it's good enough for small series.
  2. Black raven is exactly what I was thinking about when I said rts is possible on 8bit Now just to find time to code that
  3. Not bad ! How does player work ? is it rmt or something else ?
  4. It's nice to see that comparisson, thanks ! Is there source code of those tests available ? One more thing that makes sense for asm coding is memory. I haven't used pascal or those basic variants, but cc65 memory footprint does tend to blow up quickly. So even if you can make things fast enough you find yourself not finding space for them
  5. Share code, sure, great idea Maybe someone won't like it, but it's written using "c64" kickassembler All I did to make it work was to add some bytes in start and end of output bin so it's regular Atari xex file. Kickass has so many nice scripting features that I just couldn't go back to Mads after couple c64 demo projects I did last year... Entire source code is in couple asm files (main code and memory map, var definition file) and single python script that does gfx conversion from couple pngs (tiles, sprites, cursor, font, title screen, map). For a turn based game I agree with you about madpascal or even cc65. This realtime thing with map 96x96 and zombie every 10 cells roughly, means there's 1000 enemies to process. Trust me, all that looking where zombie should go, path finding, attack, erase, draw takes time... Of course there are tricks like process only what's on screen and do as much as you can outside that "current player focus" area. It's great fun, I encourage everybody who has any coding skill to just try
  6. Yes. I'm working on shooting arrow animation, need to balance some numbers, and add some effects for house attack etc... To be honest I never played till I've reached edge of map, so my guess there are some bugs when you build stuff close to edge too... Forgive me
  7. Don't know about world of warcraft but warcraft 1 sure why not
  8. Yeah, didn't have time to finish shooting arrows, but they do kill them and maybe too easy... I'll balance game till voting is finished, so gameplay will be better. I didn't have time to properly test it as I was making it playable in last couple hours till deadline Map is filled with zombies at start, and they move randomly... But as time goes, they become more and more aggressive till they just think about one thing and that is getting to the middle where your start house is. And if they come in contact with anything in between they destroy it slowly. I wish char mode would have more colors, but even then I would go for bitmap next time and make sprites move pixel by pixel. I must repeat, we need more rts and turn based games. Dune, C&C, battle issle, panzer general type of games...
  9. Hi ! Here is a small video with part of gameplay from "They are many". Game is kind of real time strategy with gathering resources, building stuff, moving units around, and trying to resist incoming zombie attacks that grow in strength over time. I haven't managed to squeeze in every planed thing into it before deadline but I hope it's enough to show games such as this are totally possible on A8. We need more games like this imho. Coderz please consider building much more complex worlds and game mechanics. Cheers ! PopMilo ps. There's only one sfx (shoot) in game, so please put on some atmospheric music in your room before playing the game
  10. Not bad at all ! Reminds me of Astro marine corps from c64/speccy/amstrad (in a good way)
  11. Nice ! I love going behind objects and that you dare to move screen and sprite in "char res"
  12. I'm not exactly sure what's "change_font" doing, but I'll asume it's your current charset address high byte. For direct "calc" method (shorter code) I would do: lda character sta change_bck+1 lda #0 asl change_bck+1 rol asl change_bck+1 rol asl change_bck+1 rol ; now we have character*8 in hi-lo form in accumulator and change_bck+1 adc change_font+2 ; no need for clc as carry is zero for sure sta change_bck+2 It's little shorter than your version, but could be even more cycles because of more asl operations with zp var (if change_bck is on zp ?). But... Best way is table for sure: ldx character lda tab_lo,x sta change_bck+1 lda tab_hi,x clc adc change_font+2 sta change_bck+2 Where: tab_lo: .fill 128, <(i*8) tab_hi: .fill 128, >(i*8) Even better... Have table values with hard encoded charset base address. ldx character lda tab_lo,x sta change_bck+1 lda tab_hi,x sta change_bck+2 tab_lo: .fill 128, <(base+i*8) tab_hi: .fill 128, >(base+i*8)
  13. THat could work Gemintronic, if he can have enough cpu cycles for that... I did procedural generation in Monk and algorithm was indeed based on random number generator, so in theory could've been 256 unique worlds 128x128 tiles each... But it was all calculated at start. Once game starts no more complex calc. ps. I had "stamps" exactly like you talk about with cactus, trees, flowers etc... Cool ideas.., s
  14. I would say you've started in a right direction, and I wouldn't rule out disk load from time to time... Games like Zelda were coded with abstractions similar to yours just applied over more levels. Something like: - "Base tiles" 2x2 chars (wood, grass, stone, bricks, roads etc). - "Large tiles" 4x4 base tiles (8x8 chars) (Tree, part of house, edge of mountain, river etc...). - Part of level close to screen size made from 4x4 "large tiles" (forest, clearing, rocky area, desert etc... (total of 32x32 chars size)) If you look at something like original NES rpg games there are those screen sized rooms, caves, dungeons where only difference is which wall has a door or which enemies are inside... One room like that was probably just couple bytes in mem. So base tiles could be 256x4 = 1 Kb large tiles = 256x16 = 4Kb large "parts" = 256x16 = 4Kb And finally map could be = 64x64 = 4Kb ----------------------------------------------------- Total: 13Kb for map of 2048x2048 chars... Thats 50x80 screens Play with sizes a little and whole map size can explode to what ever you want And all this without touching something like RLE compression of same tiles in a row... On speed of draw I would say best solution is to "draw only parts that change". There are methods like nes does with same principle possible on Atari too. Reserve 2 or 4 times size of screen and then "just" change display list pointers and draw "new stuff" that comes into screen.
  • Create New...