+karri Posted February 20, 2020 Author Share Posted February 20, 2020 20 minutes ago, 42bs said: sprpck has the -c option to compress the color table, which I found also helpful. So if the part of your sprite (or portion of a bigger one) uses only 8 color it will use only 3 bit. Not sure if that's what you mean with the pen option. That is exactly what I aim for with the "penpal" option. I was thinking about automatic compression of the palette. But it could be difficult to understand how the mapping was done. Perhaps I should introduce something like -c and then it would output the resulting mapping "penpal". Now I try to get together a tutorial with one graphics sheet and a small C-project that creates a small game using these sp65 features. Quote Link to comment Share on other sites More sharing options...
42bs Posted February 20, 2020 Share Posted February 20, 2020 But with penpal, you have to know which pens to use. The -c option returns the redirection table for the colors used in the sprite. 1 Quote Link to comment Share on other sites More sharing options...
+karri Posted February 20, 2020 Author Share Posted February 20, 2020 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. Quote Link to comment Share on other sites More sharing options...
42bs Posted February 20, 2020 Share Posted February 20, 2020 (edited) But the player sprite needs transparent colors if it contains "holes". For example if it is walking. Maybe I do not get the "edge" approach completely. Edited February 20, 2020 by 42bs Quote Link to comment Share on other sites More sharing options...
42bs Posted February 20, 2020 Share Posted February 20, 2020 BTW: Do you have an example image where the new packing algo gives a benefit? Quote Link to comment Share on other sites More sharing options...
PetrS Posted February 20, 2020 Share Posted February 20, 2020 3 hours ago, karri said: I just pushed the new version. The ay=mid, ax=max options are now available. There is also a new option "pen" available. The idea is that you can have a single graphics image that could be 4 bit deep (for 16 colours). When you slice and area you can map the colours into a 2-bit sprite by defining the option -c lynx-sprite,pen=089a This would greate the new sprite as a 4-colour sprite and map the colours as the "pen" says. The effect is the same in your code later. If you draw your 4-colour sprite with the penpal = {0x08, 0x9a} you will get the correct colours on screen. The "pen" can also be to enforce a certaing depth for the sprite. So if you have a 2-colour bitmap, but you want a 16-colour sprite. -c lynx-sprite,pen=0123456789abcdef This would save the sprite as a 4-bit sprite despite that the original bitmap is something else. Awesome! Thanks Karri Quote Link to comment Share on other sites More sharing options...
+karri Posted February 20, 2020 Author Share Posted February 20, 2020 19 minutes ago, 42bs said: But the player sprite needs transparent colors if it contains "holes". For example if it is walking. Maybe I do not get the "edge" approach completely. 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. Quote Link to comment Share on other sites More sharing options...
+karri Posted February 20, 2020 Author Share Posted February 20, 2020 23 minutes ago, 42bs said: BTW: Do you have an example image where the new packing algo gives a benefit? 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. Quote Link to comment Share on other sites More sharing options...
+karri Posted February 21, 2020 Author Share Posted February 21, 2020 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 Quote Link to comment Share on other sites More sharing options...
42bs Posted February 21, 2020 Share Posted February 21, 2020 The "best packing" algo is good! The BG sprite with sprpck is 180 bytes larger. Good job. 1 Quote Link to comment Share on other sites More sharing options...
laoo Posted February 21, 2020 Share Posted February 21, 2020 (edited) 51 minutes ago, 42bs said: The "best packing" algo is good! The BG sprite with sprpck is 180 bytes larger. Good job. Which BG sprite? I'd love to test packing component in our framework (in which LQ and MK where made and which we are preparing do release) too. Edited February 21, 2020 by laoo Quote Link to comment Share on other sites More sharing options...
42bs Posted February 21, 2020 Share Posted February 21, 2020 36 minutes ago, laoo said: Which BG sprite? I'd love to test packing component in our framework (in which LQ and MK where made and which we are preparing do release) too. $(SP) -r graphics.pcx --slice 26,114,160,102 -c lynx-sprite,mode=packed -w bg.c,ident=bg,bytesperline=8 Quote Link to comment Share on other sites More sharing options...
laoo Posted February 21, 2020 Share Posted February 21, 2020 32 minutes ago, 42bs said: $(SP) -r graphics.pcx --slice 26,114,160,102 -c lynx-sprite,mode=packed -w bg.c,ident=bg,bytesperline=8 The data in bg.c is 5240 bytes. My algorithm yields 5421 which is 181 bytes more. And i'm wondering now how it is possible as I was until now pretty convinced that only reasonable algorithm to pack Suzy textures is a greedy one, so it can't be done better... 1 Quote Link to comment Share on other sites More sharing options...
+karri Posted February 21, 2020 Author Share Posted February 21, 2020 1 minute ago, laoo said: The data in bg.c is 5240 bytes. My algorithm yields 5421 which is 181 bytes more. And i'm wondering now how it is possible as I was until now pretty convinced that only reasonable algorithm to pack Suzy textures is a greedy one, so it can't be done better... 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. 1 Quote Link to comment Share on other sites More sharing options...
42bs Posted February 21, 2020 Share Posted February 21, 2020 (edited) 4 minutes ago, laoo said: The data in bg.c is 5240 bytes. My algorithm yields 5421 which is 181 bytes more. And i'm wondering now how it is possible as I was until now pretty convinced that only reasonable algorithm to pack Suzy textures is a greedy one, so it can't be done better... ? Like I thought about sprpck. Actually, I never thought it could be "optimized". But Karri proved me wrong ? I am investigating this. Edited February 21, 2020 by 42bs 1 Quote Link to comment Share on other sites More sharing options...
laoo Posted February 21, 2020 Share Posted February 21, 2020 3 minutes ago, karri said: 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. Astonishing. I have to digest this because I'm stuck with a "proof" that it's impossible. 2 minutes ago, 42bs said: I am investigation this. Likewise 1 Quote Link to comment Share on other sites More sharing options...
42bs Posted February 21, 2020 Share Posted February 21, 2020 Honestly, I do not see where the benefit comes from: Counter+Flag = 5 bits. P => RLE encoded L => literal Bits per pixel = 4 P1 => 9 P2=>9 P3=>9 L1 => 9 L2=>13 L3=17 L4 = 21 So a sequence: AABB is P2 P2 = 18 bits or literal L4 = 21 bits AABCC is P2 L1 P2 = 27 or L5 = 25 Ahhhhh, 2bits saved. Mind wrecking. 1 Quote Link to comment Share on other sites More sharing options...
Songbird Posted February 22, 2020 Share Posted February 22, 2020 Karri did a really nice job on this. What prompted the investigation: I was extracting boot screens from old 1990s game ROMs, and when I ran sprpck.exe (also from the 1990s ) on the screens, they usually ended up several hundred bytes longer than the original packed sprite. So Karri got curious as to why sprpck / sp65 were not as efficient as what Atari developers used back in the day. 2 Quote Link to comment Share on other sites More sharing options...
42bs Posted February 22, 2020 Share Posted February 22, 2020 2 hours ago, Songbird said: Karri did a really nice job on this. What prompted the investigation: I was extracting boot screens from old 1990s game ROMs, and when I ran sprpck.exe (also from the 1990s ) on the screens, they usually ended up several hundred bytes longer than the original packed sprite. So Karri got curious as to why sprpck / sp65 were not as efficient as what Atari developers used back in the day. Oh, yes. sprpck's algo is so naiv (it is from 1992!). It does not take care for certain patterns: With 4-bit sprites, there is so far only this one: AAbAA (repeating) where literal gives an advantage over packed. But with 3-bit there are some more and I did not check yet 2 and 1 bit sprites. sprpck does check if 2 or more pixels repeat then uses RLE else literal. Interessting: No one ever noticed that it is so bad. Thanks Carl and Karri for pointing this out. (I really mean it!) 1 Quote Link to comment Share on other sites More sharing options...
+karri Posted February 22, 2020 Author Share Posted February 22, 2020 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. Quote Link to comment Share on other sites More sharing options...
+karri Posted February 22, 2020 Author Share Posted February 22, 2020 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. Quote Link to comment Share on other sites More sharing options...
LordKraken Posted February 22, 2020 Share Posted February 22, 2020 Bra jobbat Karri Just wondering before digging into the tool, could I safely switch to sp65 considering I'm still using the old toolset (newcc65 and such)? Quote Link to comment Share on other sites More sharing options...
+karri Posted February 22, 2020 Author Share Posted February 22, 2020 14 minutes ago, LordKraken said: Bra jobbat Karri Just wondering before digging into the tool, could I safely switch to sp65 considering I'm still using the old toolset (newcc65 and such)? 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 $@ $(AFLAGS) $*.s $(RM) $*.s $(RM) $*.pal $(RM) $*.spr Quote Link to comment Share on other sites More sharing options...
Songbird Posted February 22, 2020 Share Posted February 22, 2020 Bastian, any chance you would want to update sprpck.exe with the better packing algo? I prefer running native Windows apps to Cygwin. 1 Quote Link to comment Share on other sites More sharing options...
42bs Posted February 22, 2020 Share Posted February 22, 2020 2 hours ago, Songbird said: Bastian, any chance you would want to update sprpck.exe with the better packing algo? I prefer running native Windows apps to Cygwin. sprpck needs some cleaning but I want to put it on my github. I want to include the BMP patch and - of course - the optimizing of the compression bugs me. 3 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.