|
ForumsSega Master System / Mark III / Game GearSG-1000 / SC-3000 / SF-7000 / OMV |
Home - Forums - Games - Scans - Maps - Cheats - Credits Music - Videos - Development - Hacks - Translations - Homebrew |
Goto page Previous 1, 2, 3, 4 Next |
Author | Message |
---|---|
|
Posted: Tue Aug 08, 2017 11:37 am |
I won't force anyone to use 8x16 sprites, so it'll be nice to have different functions depending on the sprite mode being used.... | |
|
Posted: Tue Aug 08, 2017 12:08 pm |
A general metasprite rutine would take N sprites and accept a string of offsets and tile numbers for each sprite. That would cover all cases. This is, for instance, what neslib uses and it works great.
It could use (internally) SpriteTableXN and SpriteTableY directly for maximum speed. This is a portion of my own set of extensions (which I've been using in tests and stuff I'm developing): #include "SMSlib.h"
#include "SMSlib_common.c" #if MAXSPRITES==64 extern unsigned char SpriteTableY [MAXSPRITES]; #else extern unsigned char SpriteTableY [MAXSPRITES + 1]; #endif extern unsigned char SpriteTableXN [MAXSPRITES * 2]; extern unsigned char SpriteNextFree; unsigned char xx, yy, xw, x0; unsigned char *stXN, *stY, *stAux; unsigned char mtgrdx, mtgrdy; void SMS_MT_initSpritesEx (unsigned char initial) { SpriteNextFree = initial; stY = &SpriteTableY [SpriteNextFree]; stXN = &SpriteTableXN [SpriteNextFree * 2]; } void SMS_MT_finalizeSpritesEx (void) { *stY = 0xD0; } void SMS_MT_addSpriteFast (unsigned char x, unsigned char y, unsigned char tile) { *stY ++ = y; *stXN ++ = x; *stXN ++ = tile; } void SMS_MT_setSpriteFastAt (unsigned char x, unsigned char y, unsigned char sprite, unsigned char tile) { SpriteTableY [sprite] = y; stAux = &SpriteTableXN [sprite + sprite]; *stAux++ = x; *stAux = tile; } void SMS_MT_addMetaspriteSimple (unsigned char x, unsigned char y, unsigned char *metasprite) { // Read header: xorg, yorg, w h mtgrdx = x + *metasprite ++; mtgrdy = y + *metasprite ++; xw = *metasprite ++; yy = *metasprite ++; // Iterate x0 = mtgrdx; while (yy --) { mtgrdx = x0; xx = xw; while (xx --) { *stY ++ = mtgrdy; *stXN ++ = mtgrdx; *stXN ++ = *metasprite ++; SpriteNextFree ++; mtgrdx += 8; } mtgrdy += 8; } } I also have dedicated functions for 16x16 or 16x24 metasprites (unrolled writes, no checks), but I think that's beyond the scope of this library. Disclaimer: Sorry for the extensive use of pointers to run through arrays. I'm so used to z88dk which produces (or produced) better code when I do it this way. Maybe SDCC doesn't, I have still to check. |
|
|
Posted: Tue Aug 08, 2017 1:17 pm |
Nice trade-off na_th_an (the stY and stXN pointers) ... but I suspect now that I rewrote the function in asm this 'trick' wouldn't save much, if all, because of course I would save the "add hl,bc" instruction but I would then have to update the pointers thus probably spending the same...
As for your metasprite routine... you said you defined some 'stripe' of sprites, but it seems to me it's some sort of w x h matrix of sprites with some initial offset, instead, so I don't get it. :( Do you know if there's some algorithm to break down an image into the smaller number of rectangles (8x8 or 8x16 for instance) so that each non-zero pixel of the original image falls at least in a single rectangle? This would probably save a few sprites, compared to a matrix. Because it might be interesting to create an exporter that takes PNGs and automatically creates a single bank of tiles and a set of stripes of rectangles so that to draw one you could pass it to some addSpritesStripe() function? That would be interesting... |
|
|
Posted: Tue Aug 08, 2017 2:38 pm |
na_th_an already has that for nes :-P. I used a not so elegant solution for the game I did in the minijam: https://github.com/kusfo/mastersystembrawler/tree/master/tools And it produces something like that: https://github.com/kusfo/mastersystembrawler/blob/master/playercharacter.h But this too much overkill for a generic solution, but maybe something in the middle ground would be great. |
|
|
Posted: Wed Aug 09, 2017 1:58 am |
I thought PSGlib + SMSlib + tools = devkitSMS :) Anything that was c in PSGlib and SMSlib are implemented in asm although I think a lot was in asm already. Except for one big function, the aiden compress thing IIRC.
Heh :) You're welcome to it. If you find a better way I'll just grab that too.
In z88dk we separate the asm implementation from the c interface. This way asm programmers can use the library without any c overhead and we can support any c compiler (or other language) that comes out. Right now the c compilers supported by z88dk are sccz80, zsdcc (improved sdcc) and clang/sdcc (that's clang on top of sdcc). clang/sdcc still has problems and it does not produce as good code as the other two compilers. So the asm implementation is in: https://github.com/z88dk/z88dk/tree/master/libsrc/_DEVELOPMENT/arch/sms/SMSlib/z... The c interface for zsdcc is closeby: https://github.com/z88dk/z88dk/tree/master/libsrc/_DEVELOPMENT/arch/sms/SMSlib/c... We always prefer fastcall + callee linkage for functions because they lead to smaller and faster code. The headers are created to ensure the compilers use those linkages whenever they can: https://github.com/z88dk/z88dk/blob/master/include/_DEVELOPMENT/sdcc/arch/sms/SM... However, function pointers must be called via standard linkage. So two c interfaces are maintained for each function - one using fastcall/callee and the other using standard linkage for function pointers. |
|
|
Posted: Wed Aug 09, 2017 8:39 am |
Thanks for the in deep explanation - very interesting and useful
oh, in that sense you're right. PSGlib was anyway native z80 asm in his own repository... and the 'one big function' was surely loadSTMcompressedTileMapArea as the PSGaiden one was already asm (IIRC!) |
|
|
Posted: Thu Aug 17, 2017 3:33 pm |
I just wrote support for 1bpp tiles - since in VRAM they'll be 4bpp anyway I thought that it would be nice to have the option to choose which two palette entries will be used.
SMS_load1bppTiles (void *src, unsigned int tilefrom, unsigned int size, unsigned char color0, unsigned char color1)
Done that, I'm working on having some simple text renderer... nothing too complicated (not a real console, I mean!) ... just something simple, but that can anyway be tailored to the need. So, for instance, the ASCII-to-tile offset won't be fixed, thus having both the chance of allocating the font tiles wherever you want them (you don't need to have them from tile 0 on...) and you can also have fonts that doesn't start at ASCII 32 (space). SMS_configureTextRenderer (signed int ascii_to_tile_offset)
Finally, I thought about adding a single 'quick' function that would 'automatically' load some standard font, set palette entries for it, configure the text renderer and turn on the screen so that one could actually code (very) simple programs simply by calling this function and writing on the screen. Of course everyone knows one of the most difficult things in computer science is naming things: what should be this last function's name in your opinion? I can't find anything better than SMS_autoSetUpTextRenderer (void)
which I fear isn't enough self-explanatory. Whatever the name, the result should be that something like this would work out of the box: #include <stdio.h>
#include "SMSlib.h" void main (void) { // 'automatically' load character set into tiles and set palette entries, then turn on screen SMS_autoSetUpTextRenderer(); // and just write using stdio's printf printf("Hello World!"); } (also, who can provide a 1bpp font (ASCII 32 to 127) that we can ship with devkitSMS with no licensing problems? should this community draw his own?) |
|
|
Posted: Thu Aug 17, 2017 8:40 pm |
Ummm... dont want to bother but...
Any more or less serious game (a least with more or less serious backgrounds) will not take a full 32-127 text palette (96 chars ough!) Phaser, by example, even without any memory limitation (could load thousands of bitmap fonts at same time) lets you set your bitmap text format (0-255, 32-96, 32-127, 65-96, etc). I would take this on count, at least to load only a numbers+capital letters(42 tiles, with two offsets) or the group 32-96 only (64)... |
|
|
Posted: Fri Aug 18, 2017 7:53 am |
I totally agree, that's why I won't ever suggest to use that function for any serious stuff. If you want to get serious, you'll surely create, convert and upload your own fonts, either 1bpp or full-color, using the palette entries you prefer, and then configure the text renderer according to the set you're using. That last function is instead meant for quick and dirty text setup - it'll even include a 'default devkitSMS' font so that you don't even have to worry about making (or finding) and converting one... |
|
|
Posted: Fri Aug 18, 2017 8:50 am |
update rolled. 1bpp tiles can be loaded using SMS_load1bppTiles() and SMS_configureTextRenderer() sets which offset will be applied to each ASCII char to generate the tile number, which can be quite 'abused' as you can also force that to use sprite palette or tile priority or even flipping tiles horizontally and/or vertically, as in my tests (see the attached image)
the 'autoSetUp' function will be released later, when I'll have a font to include - and a nice name for it. It'll take some time :| |
|
|
Posted: Fri Aug 18, 2017 6:25 pm |
Can you port the fast aPLib decompressor? It uses the index registers so it may be tricky.
I can find a few 8x8 fonts (often in the form of C headers, strangely) and discussions where people say fonts are not subject to copyright in the USA, on the assumption that that applies everywhere. You're welcome to take the font from the Phantasy Star retranslation: https://github.com/maxim-zhao/psrp/blob/master/psrp/new_graphics/font1.png plus https://github.com/maxim-zhao/psrp/blob/master/psrp/new_graphics/font2.png although I don't actually know where it came from originally. |
|
|
Posted: Sat Aug 19, 2017 1:34 am |
Is color0 background and color1 foreground? There is an asm implementation of this function in z88dk btw :) https://github.com/z88dk/z88dk/blob/master/libsrc/_DEVELOPMENT/arch/sms/misc/z80...
There are hundreds available from the spectrum and c64 communities of varying quality. Perhaps the most accessible are the c64 ones: http://kofler.dot.at/c64/font_01.html There are probably a couple of good ones in there but if you have the inspiration and time I'd say make an sms original. Edit: after looking at that link, that's not really a great source. This one is better: http://www.worldofspectrum.org/pub/sinclair/games-extras/8bitFontCollectionThe_F... but the fonts are contained as binaries inside a tape file. http://www.worldofspectrum.org/pub/sinclair/utils/8bitFontCollectionThe.tzx.zip If you find something you like you would have to save it out as a binary from a spectrum emulator or use one of the pc font editors around. |
|
|
Posted: Sat Aug 19, 2017 1:27 pm |
Thanks for the font suggestions, but I'd prefer a font with standard ASCII glyphs from number 32 to 127 (inclusive) and which we're sure were it comes from and that we're surely licensed to use - I want to avoid any trouble here, you see, as I will ship that into the library.
I'd love to ship an SMS Power! original font, but I lack the skills to do one myself - by chance anyone in this community would like to tackle this task? :) @AA: color0 is what bits at 0 will become, color1 is what bits at 1 will become (which usually is foreground, sure!) - also, I'll spy on your Z80 ASM implementation of course, thanks! :) @Maxim: fast aPlib? Where? :) |
|
|
Posted: Sat Aug 19, 2017 1:42 pm |
Fonts are hard to make readable and avoid being based on something else.
Fast aPLib here: https://github.com/maxim-zhao/bmp2tilecompressors/blob/master/decompressors/aPLi... is twice as fast in my arbitrary test, but 30 bytes larger. |
|
|
Posted: Mon Aug 21, 2017 3:18 pm |
before I start working on this, is it your code? if so, would it be OK to ship that (or something derived from that) with devkitSMS/SMSlib? :) |
|
|
Posted: Mon Aug 21, 2017 6:08 pm |
Unfortunately not, there are a few people in the credits. More here: http://www.smspower.org/forums/15846-APLibDecompressorImprovementsPlusOtherCompr... | |
|
Posted: Tue Aug 22, 2017 8:20 am |
I see, so it's an improvement of the code I'm already shipping in devkitSMS/aPlib (which I'm not really sure it's VRAM safe actually TBH...).
Do you know the lenght of the shorter LZ run it supports? I believe it doesn't go back to read very short runs, right? (I'm asking it because I'm thinking about writing a routine optimized for VRAM copy using a small buffer, because moving one byte a time from VRAM to VRAM is a bottleneck too narrow to my taste...) |
|
|
Posted: Tue Aug 22, 2017 10:46 am |
I haven't tuned it for display-on safety, let alone interrupt safety. It makes no effort to buffer data, it always reads back, and it hits VRAM as fast as possible on the Z80. The _ldir_vram_to_vram function is probably the only place you would need to slow down, plus some di/ei where necessary to survive interrupts that change the VDP state, and (as discussed in the other thread) is where you can attempt to add buffering, but beware overlapping source and destination ranges. One interesting hack might also be to handle the case where the VDP address high byte is not changing, but inspect that would be more trouble than it's worth. | |
|
Posted: Tue Aug 22, 2017 12:20 pm |
I'm trying this ATM, but still don't know if it's worth... I mean, what's the shortest run supported by aPlib? (I don't believe it'll read back from VRAM for just one or very very few bytes, right?). Overlapping means that we need to read from VRAM a different amount of bytes than what we need to write there later, so it means I'm creating separate functions to read n bytes and to write m bytes from the buffered n bytes, it should work... |
|
|
Posted: Tue Aug 22, 2017 1:12 pm |
BTW what I'm trying to achieve is something like:
pseudocode: if (len<=buffersize) OR (dest-src<=buffersize)
n=MIN(len,dest-src) read n bytes write n,len bytes ($) else // which means (len>buffersize) AND (dest-src>buffersize) copy buffersize bytes from src to (buffer to) dest (*) update src,dest and len values and run again from top ($) "write n,len bytes" means "write len bytes from first n entries of the buffer, looping if needed" (*) meaning "read buffersize bytes, then write buffersize bytes" do you think I'm missing something? (it seems to me we should split (from your saturday post on?) this into a new topic...) |
|
|
Posted: Tue Aug 22, 2017 6:43 pm |
It can read back a single byte, I think. Part of the point of my Python decompressor mod is to print out the match details. Presumably we can compute the break even point where the buffering is worth it. | |
|
Posted: Wed Aug 23, 2017 8:00 am |
yeah, I had found out the details about how it works yesterday - yes, it can read back just 1 byte, and in that case any effort to optimize that is pretty much useless. But if needs to read back say 4 or 5 bytes and write them two times in a row (which is quite possible) even having a small -say 16 bytes- buffer will help a lot, as you'll set VRAM address just once for reading and once for writing, and the reading and writing will be in tight loops too as in:
; *****************************************************************************
; read B bytes from VRAM (HL) into buffer ; IN: HL source VRAM address ; IN: B number of bytes (1 <= x <= sizeof(buffer)) ; clobbers: BC,HL,Flags read_VRAM_to_buffer: ld c,$bf di ; *interrupt safe* out (c),l out (c),h ei ; 4 ld c,$be ; 7 ld hl,buffer ; 10 sub $00 ; 7 = *VRAM safe* (this is an useless opcode just to slow down) _ini: ini ; 16 jr nz,_ini ; 12 = *VRAM safe* ret |
|
|
Posted: Wed Aug 23, 2017 11:57 am |
back on the original topic... do you like this font? it's the CGA font - according to what I've read it's "public domain" as its copyright has now expired. I find it easily readable so I think it can be a nice fit...
|
|
|
Posted: Wed Aug 23, 2017 12:45 pm |
It's quite nice Sverx!
If you want to try something different, some years ago, I was following Patroclus (David Senabre) Z80 tutorial for Master System, and he was using the colecovision font, but I haven't been able to find if they're copyright free or no now. I still have the bin resources for master system of this coleco font, the bbc micro one... |
|
|
Posted: Wed Aug 23, 2017 1:36 pm |
Most discussions I read considered bitmap fonts to be not subject to copyright anyway.
http://stason.org/TULARC/business/copyright/3-9-Are-fonts-copyrighted.html Personally, I dislike this font for body text - it feels like an ideal font to encourage people to use something else. The BBC Micro one is more comfortable to read (two pixel verticals, few serifs), but there are better ones. Have a look through https://int10h.org/oldschool-pc-fonts/fontlist/ for example, I think the Amstrad PC1512 font is pretty good. The Amiga Topaz 8x8 is pretty nice too. |
|
|
Posted: Wed Aug 23, 2017 2:25 pm |
which isn't something bad ;) LOL! :D seriously: I don't know. I need more feedback please! |
|
|
Posted: Wed Aug 23, 2017 4:01 pm |
That CGA font is pretty terrible, imo. Serifs are always a bad idea for low res fonts and the "dancing" baseline of the lowercase letters really reduce the readability. | |
|
Posted: Wed Aug 23, 2017 5:06 pm |
I'm using this one :
http://www.dafont.com/fr/amiga-forever.font a very readable font ! |
|
|
Posted: Wed Aug 23, 2017 6:22 pm |
That's Amiga Topaz 8x8! The issue here is confidence in the copyright or otherwise, but I suspect it is not an issue. | |
|
Posted: Wed Aug 23, 2017 8:37 pm |
I'd really like to avoid copyright troubles - but OK, I'll seek a different font.
Help me if you can locate 8x8 fonts which are surely *free* |
|
|
Posted: Thu Aug 24, 2017 5:54 am |
I can find you fonts on GitHub with CC licences - but they're still copied from old bitmaps. This one claims to be PD: https://github.com/dhepper/font8x8 but lacks a nice bitmap preview. | |
|
Posted: Thu Aug 24, 2017 8:00 am |
I found that too a few days ago, I skipped it for the same reason (I mean, I had hoped to find a BMP/PNG/GIF to convert myself to 1bpp...)
Do you know where I could find the BBC micro one you mentioned yesterday? I can't find it myself - my google-fu is getting worse with each day :| |
|
|
Posted: Thu Aug 24, 2017 12:06 pm |
This site has it, plus lots more: https://damieng.com/blog/2011/02/20/typography-in-8-bits-system-fonts | |
|
Posted: Thu Aug 24, 2017 12:19 pm |
Alternatively, I have all of these fonts already converted to master system binary resources:
https://www.dropbox.com/sh/07lykmpbbb9f8pj/AADm7XZMRJlrVnbEaAn2fcd1a?dl=0 I hope they work for you! |
|
|
Posted: Thu Aug 24, 2017 12:35 pm |
seems like 2 chars are missing from that PNG (126 and 127) and ASCII 96 is a £ instead of a `, so I copied those from that other font... check if it might go now. Or suggest improvements :)
|
|
|
Posted: Mon Aug 28, 2017 9:01 am |
update rolled, just before the weekend.
I hope the font is fine the way it is now :) |
|
|
Posted: Wed Oct 04, 2017 11:12 am |
As promised, I'm working on a function to place TWO side-by-side sprites onscreen with a single call. It'll support both normal (8x8) and tall (8x16) hardware sprites, also when zoomed. This is useful for instance if you're using many 16x16 sprites, as it'll save more than a few cycles (to add two sprites it'll require only approx 40% more of what is required to add a single sprite)
Anyway I'm lacking a good name for the function. SMS_addTwoSprites() isn't enough descriptive IMHO but I really can't get with a good name. You know the old saying of what it's really hard in computer science... |
|
|
Posted: Wed Oct 04, 2017 11:53 am |
addDoubleSprite()? | |
|
Posted: Wed Oct 04, 2017 12:25 pm |
I like that even less :(
The point is that the name should somehow explain exactly that you're placing two sprites, both at the same Y and at different X so that the second begins exactly where the first ends, as if they were welded... 'double' doesn't convey this idea at all :| |
|
|
Posted: Wed Oct 04, 2017 12:39 pm |
AddHorizontalArrayOfTwoSprites? | |
|
Posted: Wed Oct 04, 2017 1:23 pm |
would you ever memorize that? if I do, I'll then surely forget the PIN of my ATM card... | |
|
Posted: Wed Oct 04, 2017 3:21 pm |
what about SMS_addTwoAdjoiningSprites? | |
|
Posted: Wed Oct 04, 2017 5:57 pm |
I suppose you are planning an array nxm function...
Ideal for bosses |
|
|
Posted: Wed Oct 04, 2017 7:59 pm |
SMS_addSpritePair()? | |
|
Posted: Wed Oct 04, 2017 9:01 pm |
I feel like this should extend to any rectangle of sprites, maybe with a macro to avoid conditionals? Then at least the name would be easier. | |
|
Posted: Thu Oct 05, 2017 8:18 am |
@kusfo: SMS_addPairedSprites maybe? But I'm not so sure it conveys the idea of them being two and placed side by side
@Maxim: that would require to pass height and width of the matrix (or to build a metasprite struct somewhere in memory) and I'm (still?) not working in that direction. But please, explain me in detail what you meant so that I might consider that too later :) |
|
|
Posted: Thu Oct 05, 2017 8:34 am |
I'm imagining that you may often want to draw sprites n, n+1, ... in a rectangle of width w, height h starting at a given x, y. Maybe you might want to pass a pointer to sprite indices if they are not consecutive, but consecutive is often easy to achieve. | |
|
Posted: Thu Oct 05, 2017 8:40 am |
It looks nice, it's not very, very, clear, but sound ok |
|
|
Posted: Thu Oct 05, 2017 9:39 am Last edited by sverx on Tue May 29, 2018 11:22 am; edited 1 time in total |
@Maxim: yes, but if w=2 and h=1 and indices are consecutive, I just need to pass x,y and the tile as in SMS_addSprite... on the other hand, if w is variable, the same with h, I'd surely need to pass two more parameters, not to say about having NOT consecutive tiles.
I bet one would prefer then to have a 'real' metasprite engine instead, for instance one that lets you place only the sprites that are really used (not the empty ones, for one!) - giving each one its offset and possibly the tile number too. But that's overshooting what I'm doing here, a simple 'give me a faster way to draw two adjacent sprites which made up a single character'. Of course I'm thinking at simpler games. @kusfo: I'm still undecided. I like also SMS_addTwoAdjoiningSprites which I believe that's more to the point. I will think about that a few more days. |
|
|
Posted: Thu Oct 12, 2017 9:25 am |
... and finally, the new
void SMS_addTwoAdjoiningSprites (unsigned char x, unsigned char y, unsigned char tile);
function has been added to SMSlib - I hope you'll like it. It's way faster than doing the same with two successive calls to SMS_addSprite. it places two sprites (any size) adjoining one each other, which means: - both sprite at same 'y' - second sprite is placed at 'x+width of the sprite' (works with zoomed sprites too) - if this overflows, second sprite won't be placed (so you won't see the other half of your character on the left edge of the screen!) - second sprite tile is 'tile+1' for 8x8 sprites (and zoomed 8x8 sprites) and 'tile+2' for 8x16 sprites (and zoomed 8x16 sprites) the function doesn't return any handle. I'm wondering if someone really needs it even with SMS_addSprite... |
|
Goto page Previous 1, 2, 3, 4 Next |