Jump to content

popmilo

Members
  • Content Count

    1,678
  • Joined

  • Last visited

  • Days Won

    1

popmilo last won the day on October 23 2016

popmilo had the most liked content!

Community Reputation

1,347 Excellent

About popmilo

  • Rank
    Stargunner
  • Birthday 11/01/1973

Contact / Social Media

Profile Information

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

Recent Profile Visitors

19,905 profile views
  1. Nice ! I love going behind objects and that you dare to move screen and sprite in "char res"
  2. 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)
  3. 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
  4. 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.
  5. Guess it would help if you defined "flew over ships" better Was it view from top or sideview ?
  6. As I also have couple of atari max carts lying around, we'll make it work on those for sure
  7. Is that that done by simply not drawing column of bytes where something is in front ? Looks great !
  8. @kiwilove No worries Harvey, we love harsh words as long as they are true It's just the first prototype of that level. There will probably be dozen more gfx revisions in the future... As Doctor said, arcade isn't much better:
  9. What player is that ? Or is it some custom play routine ? Looks like it was made by this guy: https://mxd.cz/archive/
  10. Please add @TIX to wonderboy credits as graphics artist
  11. Thanks ! I did try google, but without atari keyword I thought it's some desktop pc tile editor... Didn't find anything similar. Cool, nice project it seems.
  12. May we ask what kind of software is that ? And that language you mentioned is inside that software too ? Keep on making good stuff NRV We'll wait patiently for that xex file we can load on a real machine and see it's beauty first hand
  13. Sure, it is just one of limits. Imho that 1 bit difference can be crucial in some methods. Stuff like that "encoding" gfx based on character code is very powerful. For example with 8bit char codes you can split them nicely to 4+4 bits. How do you split evenly info in 7 bits ? First symmetrical division is 3+3 and you're left with 1 extra bit that you don't know what to do with, and 3bit vs 4bit is like 8 steps instead of 16 for color or angle or dither or else. Sometimes more really is better, like A8s MHz for example
  14. Did you think about making edges of wall slanted inside one char column ? Something like 16 kind of height (4 bits), 1 bit for slope direction and 2 bit for how high it ends on neighbor character ? 16 heights per half screen is like half char precision... with slope maybe it would be enough. Ufff... Don't we hate 128 char limit of A8
×
×
  • Create New...