Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

584 Excellent

About enthusi

  • Rank

Contact / Social Media

Profile Information

  • Gender
  • 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. The shorter the time the more shallow the game will (have to) become. While you can set up a puzzle engine rather easily. It is the balancing and testing that really takes (and should!) time to be able to release a stable and proper version in the end. Not to speak of anything more in the adventure/RPG genre. If exclusive titles (and not mere ports) are wanted -and the Lynx can pull off fanatic things when pushed a little- you need rather a year than few weeks. Not full time job on 1 year of course. But people with kids for example had way LESS time during lockdown usually.
  2. In our Bastion demo we use that hardware sprite clipping for the wiping of the credits texts.
  3. It is more interesting for speed rather than space at least the use cases I know of. Not by much though. STY *+4: CMP #23 is not that bad either 🙂
  4. Very nice improvement! :) sprpck is about the only tool that I kept using and it looks like it might stay so.
  5. Nah, I love optimizing things alot In fact, to me that is what most of the fun is about. Also I do not mind people using C or BASIC or whatever if they enjoy THAT more than other options.
  6. I haven't done intensive testing but RLE packed sprites are a bit slower as far as I know, but yes, agreed - it would be a waste NOT to use it. But optimizing it for a few percent while using a c-framework does not really make sense in the end.
  7. For the bitmap gfx in Assembloids I pack the data with an individual algorithm straight into memory. Much higher packrate that simple RLE naturally.
  8. That apply to write as well though and while there is some jitter in the colors it is certainly not 0-15 cycles. But rather the remaining cycles of the interrupted opcode. It would be cool to see your analysis with ROM cart reads in a loop.
  9. I used a different approach which I think is as fast as it gets. For each color the code is: &label1=*+1 lda #00 sta $fda0 &label2=*+1 lda #00 sta $fdb0 ... Then in the same rasterline after setting up the colors, the values for the next line are set via selfmod-code: lda luchs_pal+0*102,y sta label1 lda luchs_pal+1*102,y sta label2 ... Y is the current line and simply increased (as I dont even use HBL but you could take the current line from the register as well). The data is interleaved such that this works out nicely (you can easily have scrolling images as well as I uploaded once somewhere here). So there is no need to add 32 or anything each line. Edit: with this interleave you can store the colors from the table directly lda table,y sta $fda0 ... but lda $1234,Y is slower than lda $1234. This routine was maxed out for speed.
  10. Ah sorry, I misread that then. The Textscroller in Bastion uses 14 free colors and keeps 2 colors global
  11. The one crucial optimisation you are missing is to set the colors in order of appearance. Then changing 16 colors is no problem at all.
  12. Nice. This mode has quite some potential in general! From the gfx used in the Bastion demo:
  13. We are quite happy and proud to announce the release of Assembloids for the Watara Supervision. Its first (and so far only) aftermarket game at all Here is a short unboxing video with very short gameplay:
  • Create New...