Jump to content

enthusi

Members
  • Content Count

    664
  • Joined

  • Last visited

Community Reputation

523 Excellent

About enthusi

  • Rank
    Dragonstomper

Contact / Social Media

Profile Information

  • Gender
    Male
  • Location
    Potsdam, Germany
  • Interests
    Astronomy, Assembler 6502 /07/10, C64, VCS 2600, Photography, Tapes, Coding/Reversing in general, C, Python

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Ah, good So which of the two 'hidden' images did you like more?
  2. Has anyone revealed the second hidden many-color-image yet?
  3. We have a thread where I posted my own loader and we discuss things. It sets all colors to black right from the start.
  4. For Assembloids the music was composed in an 'arbitrary' s3m tracker and converted/translated into a packed music format suited for my driver. I described that in more detail here:
  5. Yes, I agree 100% there. That's is basically all I had to say You 'should' have some idea of what you are doing and what cc65 will do with it (which is not the actual idea of C, at least not for modern plattforms).
  6. Not saying c is bad. I use it at work alot. Neither is cc65 in some ways but one should know what is happening. Here is a small c code, followed by plain cc65 output and a small manual routine. For the given task the C version is certainly fast enough still but you see at once what the costs of generic code are. https://pastebin.com/UN6UQaVY
  7. I was merely commenting on the evolution. These days few people that start with BASIC end with Assembler or even C. I have seen many great C games, last but not least in this particular year and Wyvern Tales is currently among the very best of this age, too. To truly keep a system alive and going you (also) need a certain amount of people that are willing to dig deep and code bare metal in the long run, in my experience.
  8. I fully agree to many Mark my words though: (many/some/enough) batari basic coder will not move to C for faster code and then to ASM. Instead there will be demand for larger PCBs and additional computing power. It happened before and it would again.
  9. And I for one seriously hope that people well also get into hardware details and value what the Lynx CAN do and not how anything can be done with the least effort possible.
  10. Yes, exactly like that. Even that is fast enough (just for scrolling at least ;-). 8x8 really isnt well suited for Lynx but this is just a demo.
  11. No, obviously not! I only chain enough sprites to draw a fully visible screen + one 4x4 tile to the right and bottom (it is not optimized as this were really by first footsteps :). Ideally you only draw 8 pixel into the right and bottom border, not 32 So the screen is 192x160 or so. ~ 432 sprites or in the range of that. I wrote a routine to update all points of the sprite-chain once we move by more than 1 tile.
  12. This will always work well: manufname ; 0123456789012345 .asc "PriorArt 09/2019" .dsb (manufname+16)-*,0
  13. Size and variety are the main drivers here. The map is 3072 x 2208. That are 420 full Lynx screens! Stored in ~30 KB. The full map (fullscreen attachment) consists of 32x32 tiles. But WAY too many of them to store those as sprites, either (see 2nd attachment). Those 32x32 tiles again are constructed out of 4x4 tiles with 8x8 pixel size each. And of those we only have 180 or so. THAT fits easily into memory. Of course it is an effort to make such graphics. Those were made on C64. Only very few games really tried HARD on the Atari Lynx to max out its specs in my opinion. This is quite common for any plattform with such limited commercial lifetime. I hope we will see in the time to come what this beast is really capable of. WITHOUT cheating by giving it more power or larger carts that it ever had. The last shot shows the 32x32 tiles in the full screen map.
  14. This is one of my early attempts to use chains when I started getting into Lynx. LOTS OF THEM. More than 300 in this case. The sprites mimic C64 characters and are a mere 8x8 pixel in size. The screen scrolls in pixel steps. Press Button A or B while moving for faster scrolling. The map is quite large! It consists of (iirc) 96x85 tiles. Each tile is 32x32 pixel large and consists of 4x4 characters a 8x8 pixel. The full level is 3072 x 2720 pixel large and stored as those aforementioned pointers into pointers into pointers and thus fits into those few KBs of this unpacked binary. turrican.o
×
×
  • Create New...