Jump to content

karri

+AtariAge Subscriber
  • Content Count

    3,276
  • Joined

  • Last visited

  • Days Won

    1

karri last won the day on December 31 2016

karri had the most liked content!

Community Reputation

1,270 Excellent

1 Follower

About karri

  • Rank
    River Patroller
  • Birthday May 21

Contact / Social Media

Profile Information

  • Gender
    Male
  • Location
    Espoo, Finland
  • Interests
    Swing dancing. Acting, Swing dancing. Atari Lynx programming and Swing dancing.

Recent Profile Visitors

25,223 profile views
  1. I just realized that my tool was not able to parse literal sprites. So I added a little code. Now you can extract literal sprites as well. The literal sprite has the same size as with "sprpck -u" which sounds good. -rw-r--r-- 1 karkak karkak 8365 Feb 24 12:32 test.bin shapedtest.zip
  2. One thing I have been unsure about is the effect of a filler byte at the end of the line. If the last pixel of a line is in use you need a filler byte. Would it be better to sometimes use a literal chunk just to be sure that you never need the filler byte? I assume that the shortest sequence + filler byte is always better. As the next line starts on a byte boundary it does not matter...
  3. As I promised here is a stand-alone Lynx sprite parser in Python3. The usage is in the Makefile. (Building the sprite on the first line. Creating the image from the sprite on the 2nd line) $(SP) -r original.pcx -p lynx-palette,testpal.bin -c lynx-sprite,mode=packed -w test.bin $(PYTHON) bin2pcx.py shapedtest.zip Basically the file is called bin2pcx.py It will read the sprite as a binary file as well as the palette as binary file. The output is a pcx file. After the run you can diff the pxc files diff original.pcx test.pcx The current sp25 can pack to these values: -rw-r--r-- 1 karkak karkak 5240 Feb 24 11:38 test.bin -rw-r--r-- 1 karkak karkak 32 Feb 24 11:38 testpal.bin -rw-r--r-- 1 karkak karkak 17217 Feb 24 11:38 test.pcx So anything better than 5240 bytes is of great interest. My algorithm is just a brute force attack with the assumption that you can optimize one run length at a time. This may be wrong...
  4. Lol. Perhaps we limit the depacking algorithms to the ones that is in Suzy...
  5. Nice! I can provide a tool for generating a pcx file from a sprite binary. It is part of the tools I use for re-generating sources from old binary carts. It is in python3.
  6. Thanks! I am very happy to have you guys on board with this! The small tutorial for carl to create binary files with sp65. sp65 -r test.pcx --slice 0,0,160,102 -p lynx-palette,testpal.bin -c lynx-sprite -w test.bin You should thing about sp65 as different programs concatenated to each other. Reading a file: -r test.pcx --slice x,y,w,h Extracting a palette: -p lynx-palette,testpal.bin (binary) testpal.s (asm) testpal.c (C-code) Creating a sprite: -c lynx-sprite // Lots of options ax= ay= mode=... Writing a sprite: -w test.bin // also test.s, test.c ident=test ...
  7. Sure. I hope you would share your algorithm so I could have the best compression in future sp65.
  8. Tack Alex, The output of sp65 is just bytes. It is compatible with any environment. You can output it in raw-format at binary and read it in your environment. I did use sprpck like this in the newcc65 # Rule for making a *.o file out of a *.bmp file %.o : %.bmp $(SPRPCK) -t6 -p2 $< $(ECHO) .global _$* > $*.s $(ECHO) .segment \"$(RODATA_SEGMENT)\" >> $*.s $(ECHO) _$*: .incbin \"$*.spr\" >> $*.s $(AS) -t lynx -o [email protected] $(AFLAGS) $*.s $(RM) $*.s $(RM) $*.pal $(RM) $*.spr
  9. I have also been thinking about the comment by @bs4 about the dynamic compression of colours. Perhaps I add an option "pen=opt" that would create a minimum sprite and also output the resulting penpal to a separate file "name"_pen.[c,s,raw] I just implemented it. The penpal is just printed on the screen. I did not feel the extra complexity in dealing with files is worth the effort.
  10. The other thing that really makes a difference is to stop generating data that is not needed. Typically transparent pixels towards the edges. In sp65 I plan to tackle this with a keyword "edge" and a type "shaped". You can also use "shaped" sprites with index 0 as transparent. Just define edge=0. Then you generate a smaller sprite that still has holes.
  11. The problem is that if you always look for the next set of pixels you easily end up saving less in the future. So I put all the pixels in a 32 pixel buffer and take care of the longest run first.
  12. Here is a small project. Have a look at the Makefile and the main.c. The sp65 will use all these cool new features to build the correct sprites. I included all the intermediate files also. sptest.zip
  13. Several "old time" releases seem to use it. The title sprite consists of two sprites. A single pixel full screen background drawn with ALGO3 linked with a shaped sprite that leaves some parts undrawn. Unfortunately I compare my improvements vs the old sp65. Not sprpck.
  14. True. But I would solve this by a shadow that fills the area between the legs. If you look at the sword I had to add blueish shadow to cover the hole between the face and the sword. This is mainly for showing off all the new sp65 features.
  15. The starting point is a sheet of graphics where ALL elements have 16 colours. The goal is to use SPRITE_BACKGROUND mode to the characters and not use any transparent colours. This means that I will be using the mode=shaped,edge=15 to allow the character to stop drawing the sprite when it encounters the edge.
×
×
  • Create New...