Forums

Sega Master System / Mark III / Game Gear
SG-1000 / SC-3000 / SF-7000 / OMV
Home - Forums - Games - Scans - Maps - Cheats - Credits
Music - Videos - Development - Hacks - Translations - Homebrew

View topic - devkitSMS/SMSlib - missing/requesting features

Reply to topic Goto page Previous  1, 2, 3, 4  Next
Author Message
  • Joined: 05 Sep 2013
  • Posts: 3769
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Fri Jul 01, 2016 8:32 am
Maxim wrote
It might be easier if you could generate that bank (packing the engine and data) and then incorporate it as a blob.


Yes, it would work, but then you'll have to fit all your tunes and SFXs (and the engine code itself) in 16KB, which is too much a limitation IMHO.
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14691
  • Location: London
Reply with quote
Post Posted: Fri Jul 01, 2016 8:34 am
Pretty much every game ever did that, though. If you really want to exceed it then either the engine gets some low ROM, or you could even put multiple engine + data banks in there and swap them out together.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3769
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Fri Aug 05, 2016 2:47 pm
Last edited by sverx on Mon Aug 08, 2016 11:18 am; edited 1 time in total
I just added a few functions for palette handling:

void SMS_loadBGPaletteHalfBrightness (void *palette);
void SMS_loadSpritePaletteHalfBrightness (void *palette);
void SMS_zeroBGPalette (void);
void SMS_zeroSpritePalette (void);


These can be also useful to create a very simple fade to black, but are mainly there for a quick way to show a darker version of an image (for instance you can darken a BG image and have an onscreen superimposed menu using the sprite palette) and for quickly setting all the entries to black. I hope somebody will find these useful!
  View user's profile Send private message Visit poster's website
  • Joined: 29 Mar 2012
  • Posts: 879
  • Location: Spain
Reply with quote
Post Posted: Fri Aug 05, 2016 3:22 pm
wonderful!!
  View user's profile Send private message
  • Joined: 30 Mar 2009
  • Posts: 282
Reply with quote
Post Posted: Fri Aug 05, 2016 5:07 pm
The zero palette function seems useful. Especially when you're transitioning between screen and want to clean the palette from possible left-overs. (Changing levels, or going for a gameover screen, which is mostly black, like akmw).


Any plans for a FM lib?


Also, i came here to ask about sram, but alas, it's already there, you really need to update the github wiki :)
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3769
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Fri Aug 05, 2016 9:39 pm
tibone wrote
you really need to update the github wiki :)


The wiki contains only very basic instructions on how to start... well, maybe I should expand it...
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3769
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Thu Aug 11, 2016 8:10 pm
I added one page to the wiki, with some additional info. Still not 100% done, and I have to correct some wording. Here.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3769
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Fri Sep 23, 2016 9:07 am
I'm working on adding "STM compressed tilemap area" support (to have STM compressed tilemaps of any size, even using only a portion of the screen)

There are two approaches on this:
- store the width of the tilemap into the STM file itself, thus changing its format (that would require me to rewrite the BMP2Tile plugin and you to re-process each file)
- force the user to specify the width of the image in the SMS_loadSTMcompressedTileMapArea call. That's easier but far from ideal.

What's your opinion on this?
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3769
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Wed Sep 28, 2016 3:09 pm
Update just committed. I ended up with:

sverx wrote
force the user to specify the width of the image in the SMS_loadSTMcompressedTileMapArea call.

so you can now use STMcompressed tilemaps of any size, but you should specify the tilemap's width as a 4th parameter in the SMS_loadSTMcompressedTileMapArea function.

Hopefully I also didn't break anything else... :|
  View user's profile Send private message Visit poster's website
  • Joined: 03 Oct 2016
  • Posts: 2
Reply with quote
Post Posted: Mon Oct 03, 2016 7:59 am
Hey sverx, first of all, great work with the devkit so far, very invaluable tool for us for keeping all our code nice and high level :)

One feature request I have is that a compressed tilemap would allow it to be used for scrolling. Currently I don't see a way to use those for accessing the tilemap linearly while scrolling. Or am I missing something? Are compressed tilemaps only good for static screens?
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 3769
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Mon Oct 03, 2016 8:26 am
yeah, there's no out-of-the-box way to load/scroll a compressed tilemap... and the compression scheme you opt for also depends on how you'll access the data in there (forward-only? horizontal? freely in 8 directions? that changes a lot!)
You might anyway be interested in having your (big) map split in compressed chunks and use aPLib to unpack each chunk in RAM, for instance, but that's just one of many possible approaches.
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14691
  • Location: London
Reply with quote
Post Posted: Mon Oct 03, 2016 10:47 am
Most big platformers either decompress the stage to RAM - sometimes on cart RAM so the level can be large. They do tend to use metatiles to define the level, 8x8 is too small for all but early puzzle games. The alternative is to severely restrict the level design to allow much more concise uncompressed data to be used, for example have a choice of 256 designs for individual strips of the level and then you only need a byte per strip. This is a kind of meta-metatile approach.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3769
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Mon Oct 03, 2016 12:23 pm
Is there really a commercial game using cart RAM for that? Wow! :)
  View user's profile Send private message Visit poster's website
  • Joined: 07 Oct 2015
  • Posts: 114
Reply with quote
Post Posted: Mon Oct 03, 2016 3:56 pm
Pretty common on the NES as the system only has 2Kb of built-in RAM.
  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14691
  • Location: London
Reply with quote
Post Posted: Mon Oct 03, 2016 5:44 pm
A couple of later platformers had 8KB with no battery backup. Compare to Sonic which used 4KB of the system RAM for this purpose.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3769
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Mon Oct 03, 2016 8:36 pm
BTW a game that maps 16 KB of cart RAM to $c000 (thus where the internal RAM is) has never been found, or has it?
I'm thinking about creating an additional crt0 that activates a 16 KB RAM mode, but I'm quite sure no emulator supports it.
  View user's profile Send private message Visit poster's website
  • Joined: 01 Jan 2014
  • Posts: 331
Reply with quote
Post Posted: Mon Oct 03, 2016 11:10 pm
My experience was no emulators supported it but that was two years ago. I have not tried on hardware.
  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14691
  • Location: London
Reply with quote
Post Posted: Tue Oct 04, 2016 8:15 am
Everdrive doesn't support it so it's going to be fairly useless.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3769
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Tue Oct 04, 2016 8:30 am
I supposed that too... you mean you (or someone else) actually already tested that?
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3769
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Tue Oct 04, 2016 1:59 pm
BTW I'm quite sure both the emulators and the MasterEverDrive support RAM mapped in slot2 (at $8000) and ROM paging in slot1 (at $4000) at the same time so it should theoretically be possible to have 24 KB contiguous RAM (16 KB cart RAM + 8 KB internal RAM) or am I missing something here?
  View user's profile Send private message Visit poster's website
  • Joined: 01 Jan 2014
  • Posts: 331
Reply with quote
Post Posted: Tue Oct 04, 2016 9:47 pm
Yes everdrive and most emulators support this. It is how i got the zexall data export stuff working.

Both everdrive and most major emulators support 2x 16k cart ram either of which can be switched in to slot2. The data persists when switched out so both are potentially useful.

Pretty crazy that the sms has a potential 40k of ram sitting around.
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 3769
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Wed Oct 05, 2016 8:15 am
Well, actually I was thinking about creating a "24 KB RAM mode", having all the RAM always accessible. What I'm not really fond of is having ROM paging in slot 2. I mean, it would surely work, but would limit the code to the first 16 KB ROM only, as I can't page out code easily (SDCC unfortunately doesn't yet give automatic paging support...)
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14691
  • Location: London
Reply with quote
Post Posted: Wed Oct 05, 2016 9:16 am
Do you easily get to more than 16KB code? It seems like a lot.
  View user's profile Send private message Visit poster's website
  • Joined: 01 Jan 2014
  • Posts: 331
Reply with quote
Post Posted: Wed Oct 05, 2016 9:38 am
Well if it is a feature the programmer makes a decision to turn on knowing the caveats then no one can complain.

It is not like the everdrive page 0 issues.
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 3769
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Wed Oct 05, 2016 11:01 am
Maxim wrote
Do you easily get to more than 16KB code?


Well, not so easily, but it can happen if the project becomes complex. The stuff I'm working on it's currently at around 19 KB code.

@psidum: true, I just have to see if it's worth...
  View user's profile Send private message Visit poster's website
  • Joined: 07 Oct 2015
  • Posts: 114
Reply with quote
Post Posted: Tue Jan 03, 2017 10:25 am
Thread necromancing a bit... :)

Is there anything in the library to make side scrolling easier? I mean, copying a column of tiles to the nametable as fast as possible. You can use the unsafe VRAMmemcpy funcions as the data to be written is not contiguous (each tile has to be written 64 bytes appart), and having to call the SMS_setAddr and SMS_setTile functions for every tile seems slow.

I'm not sure how could I implement this myself optimally. Considering I manage to put into DE the column address in the VDP, and that HL points to the buffer, would this work,

ld bc, 64

; repeat 24 times:
ASM_DE_TO_VDP_CONTROL
ASM_HL_TO_VDP_DATA
inc hl
inc hl
ex de, hl
add hl, bc
ex hl, de


is there a better way?

My goal is having something I can call during vblank to push a buffered column of tiles as fast as possible.
  View user's profile Send private message
  • Joined: 07 Oct 2015
  • Posts: 114
Reply with quote
Post Posted: Tue Jan 03, 2017 12:36 pm
First, untested draft (can't do it now). Probably a mess, but my Z80 is shyte and my knowledge about SDCC inline assembly is nil.

#pragma disable_warning 85
void UNSAFE_SMS_MT_ScrollUpdateVDP (void *src, unsigned int column) {
__asm

    ; Get parameters from the stack

    pop bc
    pop de          ; *tiles
    pop hl          ; column
    push hl
    push de
    push bc

    ; Get address from column, set control bits = 01 (write to VRAM)

    add hl, hl      ; column * 2
    ld bc, #0x7800  ; Address = (01) (11 1000 0000 0000)
    add hl, bc

    ; Draw 24 tiles

    .rept   24

        ; hl -> address in VRAM
        ; de -> points to next tile in buffer

        push hl

        ; write address to control port

        ld a, l
        out (_VDPControlPort), a
        ld a, h
        out (_VDPControlPort), a

        ; write new tile

        ld h, d
        ld l, e

        ld c, #_VDPDataPort
        outi
        outi

        ld d, h
        ld e, l

        ; now de points to the next tile in buffer

        pop hl

        ; Next row
        ld bc, #0x40
        add hl, bc

    .endm

__endasm;

}


suggestions? corrections? pointers?

EDIT:: Small syntax corrections. Still untested.
EDIT:: Tested now, does nothing XD back to the drawing board!
EDIT:: Works now! It seems that I was POPing the parameters in reverse order.

I wonder if this is good code or if it could be improved?
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 3769
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Tue Jan 03, 2017 2:55 pm
Actually I never wrote a single function to do that because I thought that wasn't really necessary... after all, the slow part is that we need to update the VRAM address for each tile and -put it as you wish- you can't skip that.

So I would simply do something like (say we want to update column number 31 with contents from data[] array) [untested code]

unsigned int address=XYtoADDR(31,0);
unsigned int *p=data;
unsigned char i=24;
do {
  SMS_setNextTileatAddr(address)
  address+=64;
  SMS_setTile(*p++);
} while (--i!=0);


or something along this way...

edit: if you're using an up-to-date version of devkitSMS/SMSlib, the two function calls will turn into RST opcodes, and there also won't be any stack pushing/popping for those calls. Of course, if you need to squeeze to the last available CPU cycle, you can write your own inlined ASM... as a last resort ;)
  View user's profile Send private message Visit poster's website
  • Joined: 07 Oct 2015
  • Posts: 114
Reply with quote
Post Posted: Tue Jan 03, 2017 8:58 pm
Well, at least the inlined version works and fits in the little spare vblank time I have, right after the "unsafe" copy of the SAT. I need every cycle, many fixed point stuff going around :)

I found a small optimization, in case somebody is interested:

#pragma disable_warning 85
void UNSAFE_SMS_MT_ScrollUpdateVDP (void *src, unsigned int column) {
__asm

   ; Get parameters from the stack

   pop bc
   pop de         ; *src
   pop hl         ; column
   push hl
   push de
   push bc

   ; Get address from column, set control bits = 01 (write to VRAM)

   add hl, hl      ; column * 2
   ld bc, #0x7800   ; Address = (01) (11 1000 0000 0000)
   add hl, bc

   ; Draw 24 tiles

   .rept   24

      ; hl -> address in VRAM
      ; de -> points to next tile in buffer

      push hl

      ; write address to control port

      ld a, l
      out (_VDPControlPort), a
      ld a, h
      out (_VDPControlPort), a

      ; write new tile

      ex de, hl

      ld c, #_VDPDataPort
      outi
      outi

      ex de, hl

      ; now de points to the next tile in buffer

      pop hl

      ; Next row
      ld bc, #0x40
      add hl, bc

   .endm

__endasm;

}


Not the last library version I'm afraid. I'm too much into this project to switch right away. I'll finish this project first, then I'll update for the next :) (I'm using a version from around July last year).
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 3769
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Wed Jan 04, 2017 9:33 am
na_th_an wrote
Not the last library version I'm afraid. I'm too much into this project to switch right away. I'll finish this project first, then I'll update for the next :) (I'm using a version from around July last year).


I'm quite sure you wouldn't even notice you're switching... well, I would anyway prepare a big backup ;)

As for the column tile update, it happened me to think that you're probably worrying too much... let me explain what I mean :)

You said you 'preload' the tiles in some array and later you try to update the VRAM column of tiles as fast as possible, all during vblank.
You probably would spend less time instead not pre-loading those tiles, given that they're probably somewhere in ROM evenly spaced, so you just need to add some specific value to the 'source' pointer and let the loop copy, and you don't need to complete this task while in vblank if using SMS_setTile() as it's VRAM safe.
  View user's profile Send private message Visit poster's website
  • Joined: 07 Oct 2015
  • Posts: 114
Reply with quote
Post Posted: Wed Jan 04, 2017 2:15 pm
Storing every tile would eat my rom space. My maps are made of mapped metatiles. Every byte in the map refers to a metatile composed by 2x2 tiles. I have a table with 4 words per metatile.

I have to build the buffer looking at the metatiles and what tiles make each of them, then copy the buffer to VRAM

I build the buffer during frame time, a bit each frame. When a new column of tiles is needed the buffer is ready. That combines nicely with other tasks I have to do.
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 3769
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Wed Jan 04, 2017 2:40 pm
...cunning! I wonder if you're scrolling in one direction only (say 'right') or you can make that work for both directions freely, and you can even change direction when halfway... that would be a really nice piece of code! (and I suspect you are loading 3 [or likely even 4] tiles for each pixel you move so that when you moved 8 pixels you're done...)

Also, remember you promised us you'll be explaining how to use a map editor and handle the maps in your code :)
  View user's profile Send private message Visit poster's website
  • Joined: 07 Oct 2015
  • Posts: 114
Reply with quote
Post Posted: Wed Jan 04, 2017 9:11 pm
This will be my first scroller for the SMS and the way I've designed gameplay it will just scroll right, but scrolling both directions isn't much complicated - just slower. You have to calculate the address of the new column of tiles depending on which side of the screen you have to update. When you just have to scroll right, you just increment your pointers which is much easier.

This is certainly easier on the NES as you have a whole backscreen (in the vertical mirroring arrangement you have a nametable which is two screens wide, and your visible window cycles accross both of them, so you can draw full metatiles freely).

Yes, you are right about my promise. I will find the time to do so :) There are many ways to work with metatiled maps. I use mappy, a very simple map editor which is able to export a raw binary (1 tile = 1 byte). Then I use several custom converters to organize the data the way I need it. For a horizontal scroller, have the screens organized in columns helps quite a lot.

I also have a conversion tool which reads 16x16 pixels metatiles from a png, breaks them in 2x2 tiles, looks for duplicates, detects mirrored tiles, and builds the metatile index -> tiles lookup table for you. At the end you have something like this:

const unsigned int ts_meta0_tmaps [] = {
   0x0100, 0x0100, 0x0100, 0x0100,
   0x0101, 0x0102, 0x0103, 0x0104,
   0x0105, 0x0106, 0x0107, 0x0108,
   0x0109, 0x010A, 0x010A, 0x010B,
   0x090C, 0x090D, 0x090D, 0x090C,
   0x090E, 0x090F, 0x0910, 0x0911,
   0x0912, 0x0913, 0x0914, 0x0915,
   0x0116, 0x0117, 0x0118, 0x0119,
   0x011A, 0x011A, 0x011B, 0x011C,
   0x011D, 0x011D, 0x011E, 0x011F,
   0x0120, 0x0120, 0x0121, 0x0121,
   0x0521, 0x0521, 0x0520, 0x0520,
... etc


To draw metatile #N as referenced in the map, just read 4 words from N*4 onwards and put those 4 tiles in the nametable forming a 2x2 square. flip, palette and priority bits are built in so it's just a matter of copying the wole WORD to the nametable.

Of course you have less freedom when building your screen as the bit you use to build it are bigger, but I think they look quite nice :)
Captura.PNG (26.32 KB)
Captura.PNG

  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 3769
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Thu Jan 05, 2017 9:51 am
na_th_an wrote
This will be my first scroller for the SMS and the way I've designed gameplay it will just scroll right, but scrolling both directions isn't much complicated - just slower. You have to calculate the address of the new column of tiles depending on which side of the screen you have to update. When you just have to scroll right, you just increment your pointers which is much easier.


That 'amortized load' you're doing for the next column is what would really complicate things if you were going to scroll both left and right... that's what I meant :)

na_th_an wrote
For a horizontal scroller, have the screens organized in columns helps quite a lot.


Sure! But I guess most tools produce data in row-major order, thus you have to transpose it... or does Mappy gives you the chance to export column-mayor matrices?

na_th_an wrote
I also have a conversion tool which reads 16x16 pixels metatiles from a png, breaks them in 2x2 tiles, looks for duplicates, detects mirrored tiles, and builds the metatile index -> tiles lookup table for you.


I guess it's something that could be done directly with BMP2Tile, if you make an image which is exactly one meta-tile wide (thus 16 pixels in this case). Or am I wrong?

na_th_an wrote
Of course you have less freedom when building your screen as the bit you use to build it are bigger, but I think they look quite nice :)


They surely do! :) Please keep us posted! :)
  View user's profile Send private message Visit poster's website
  • Joined: 07 Oct 2015
  • Posts: 114
Reply with quote
Post Posted: Thu Jan 05, 2017 12:54 pm
Mappy just exports a big rectangle. You have to rely on external conversion tools to organize the metatile indexes depending on your needs. I have several converters which produce maps row-ordered (for vertical scrollers), column-ordered (for horizontal scrollers) or screen by screen (for flick screen games) in several formats (2 tiles per byte, 1 tile per byte, RLE'd, etc). Everytime we release a game you can find the converters (plus sources) in the source package.

About the metatile table I guess BMP2Tile can do it as well, but I'm used to work with wider tilemaps (easier when pixeling) and having to rearrange is one extra step. Besides, I already had the conversor working for GB and NES, I just added SMS compatibility. The tool is able to read scritps with programmed conversions, it also produces metasprites, etc. I also like to have full control over the palette, so the converter requires a small png with a pixel per colour, in the order you need them. Easier to manage palette cycles in your code.

Nothing wrong with BMP2Tile, it's only that I'm quite used to my proprietary workflow and feel hard to switch :)
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 3769
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Thu Jan 05, 2017 2:38 pm
I see, thanks! (and I understand well your point about being used to something already, but I meant using BMP2Tile for the "metatile to tile LUT", not the actual metatile "level" map...)
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3769
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Fri Aug 04, 2017 2:48 pm
Last edited by sverx on Fri Aug 04, 2017 4:03 pm; edited 1 time in total
reviving this old topic... since it seems there are no requests for additional features (or at least what's missing seems hardly missed...) I'm thinking about working on making the library faster - and smaller, when possible.
First, I'll try to convert some function calls to macros, or to macros which make fastcall calls (so to save stack push/pop time).
Beside that, which features/functions do you think require too many cycles and I should try to optimize? For instance I might turn some to native Z80 asm if there's request for that...

edit: already working on SMS_addSprite as it currently requires 394 (!!!) cpu cycles and it's easily used quite a few times each frame.
  View user's profile Send private message Visit poster's website
  • Joined: 29 Mar 2012
  • Posts: 879
  • Location: Spain
Reply with quote
Post Posted: Fri Aug 04, 2017 3:05 pm
I have a feature request, nothing that I need early, but it can be useful. To be able to switch the address of the plane nametable and the sprite attribute table (in order to do some nice tricks changing them between frames).
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 3769
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Fri Aug 04, 2017 4:08 pm
Last edited by sverx on Tue May 29, 2018 11:24 am; edited 1 time in total
kusfo wrote
To be able to switch the address of the plane nametable[...]


if it's fine for you to build your own XYtoADDR(x,y) you can already do that by using SMS_write_to_VDPRegister() (passing it the correct values, we can discuss about this possibly)

kusfo wrote
and the sprite attribute table


same here - you'll then need your own SMS_copySpritestoSAT().
  View user's profile Send private message Visit poster's website
  • Joined: 28 Jan 2017
  • Posts: 549
  • Location: Málaga, Spain
Reply with quote
Post Posted: Sat Aug 05, 2017 8:04 am
I have some requests(in no particular order):

1. 3D engine (opengl compatible if possible, with shaders of coursr)
2 http requests to do an mmorg.
3. Md5 hashing for passwords
4. Oracle db orm layer for the data.
5. Of course, for sms and gamegear (im planning resell gamegears with an sim card slot soon, last trouble i have is the battery)...
Lol

Seriously, smsdevkit is a great one :)
  View user's profile Send private message
  • Joined: 28 Jan 2017
  • Posts: 549
  • Location: Málaga, Spain
Reply with quote
Post Posted: Sat Aug 05, 2017 8:21 am
About smsaddsprite.

My new platforner draw way more sprites than astroforce (standard chaeacter is 16x32 but often i have 24x32 or bigger ones) so i am using 8x16 sprites (half of commands) as i have testing and its proven its faster that using standard 8x8 sprites.

I suppose it would be faster to reserve sprites (and change/move them) instead of add sprite every frame)

... i suppose too there is no way (an optimized function) to draw a "matrix sprite" like this:

Void drawBIGsprite8x8(x,y,rowsprites,colsprites,spritebase)

Void drawBIGsprite8x16(x,y,rowsprites,colsprites,spritebase)

This is (the last) the type of function i am using. It make several calls to smsaddsprite. It is, for sure, the most performance critical function i have.
  View user's profile Send private message
  • Joined: 28 Jan 2017
  • Posts: 549
  • Location: Málaga, Spain
Reply with quote
Post Posted: Sat Aug 05, 2017 8:34 am
In other side, i would be careful with additions, as the code space is limited :(
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 3769
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Sun Aug 06, 2017 1:50 pm
MD5 hashing: I think there are already open-source C libraries to do that, we might just check if they compile fine with SDCC ;)

About adding or modifying sprites: I'm not really sure that it's faster to reserve/modify them than to add them. Probably not, and it'll become surely slower once I publish the asm rewrited addSprite... but I can work on rewriting the other functions too, after that. I'll profile them later, so I'll tell you some more detailed info.

metasprites: you can roll your own version and it'll be faster once the addSprite API will be faster. If it still isn't enough, we can talk about some way to code a separate function.

and about additions in general: I try to break the library in small modules so that you'll only load up the modules you need. It's already doing that, it'll be doing that even better at next iteration.
  View user's profile Send private message Visit poster's website
  • Joined: 28 Jan 2017
  • Posts: 549
  • Location: Málaga, Spain
Reply with quote
Post Posted: Sun Aug 06, 2017 7:00 pm
Ummm... i dont have performance troubles now, but only though it could be interesting an optimized asm function for metasprites instead two loops with a function call to smsaddsprite with several parameters to pass, letting the compiler trying to do the best work possible. Btw smsaddsprite needs 3 params. I dont know if this force an stack based function or its possible a fastcall one.

Md5 was a joke. I see you dont comment nothing about the hw 3d engine lol :o
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 3769
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Mon Aug 07, 2017 8:07 am
meta-sprite functions are IMHO beyond the scope of devkiSMS/SMSlib (also because there are quite a few of different approaches) but, as I said, if they're really needed, we can develop together specialized functions for that, and share them with others too :)

I'm working on the 3D engine. ;)

edit: the only SDCC fastcall available ATM can work only when the function has a single parameter

2nd edit: update just rolled. SMS_addSprite() now is much faster, I shaved off approx 45% of the CPU cycles it took before.
  View user's profile Send private message Visit poster's website
  • Joined: 28 Jan 2017
  • Posts: 549
  • Location: Málaga, Spain
Reply with quote
Post Posted: Mon Aug 07, 2017 12:26 pm
Downloaded from github. We would have to ask aa for update in z88dk. If you continue optimizing the engine, pkk & aa their compilers & me learning i think we wont have to switch to sgdk lol :)
  View user's profile Send private message
  • Joined: 17 Nov 2015
  • Posts: 97
  • Location: Canada
Reply with quote
Post Posted: Mon Aug 07, 2017 5:02 pm
eruiz00 wrote
Downloaded from github. We would have to ask aa for update in z88dk.)


devkitsms is already rewritten in asm in z88dk :)

SMS_addSprite():
https://github.com/z88dk/z88dk/blob/master/libsrc/_DEVELOPMENT/arch/sms/SMSlib/z...

Linkage is callee for functions taking more than one parameter.
  View user's profile Send private message Visit poster's website
  • Joined: 28 Jan 2017
  • Posts: 549
  • Location: Málaga, Spain
Reply with quote
Post Posted: Mon Aug 07, 2017 6:31 pm
Ummmm... great!

If this can be of help, have downloaded todays versions of sdcc, z88dk and smsdevkit.

Sdcc fails, while my last sdcc version (22-7) does work ok. Compiling with optcodespeed and todays smsdevkit. Z88dk works ok with so3.

Pkk if need rom or src ask for it.
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 3769
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Tue Aug 08, 2017 7:47 am
Alcoholics Anonymous wrote
devkitsms is already rewritten in asm in z88dk


you mean SMSlib of course :)

Alcoholics Anonymous wrote

SMS_addSprite():
https://github.com/z88dk/z88dk/blob/master/libsrc/_DEVELOPMENT/arch/sms/SMSlib/z...
Linkage is callee for functions taking more than one parameter.


Ok, next time I'll copy your asm instead of writing my own ;)
BTW I don't get how you're passing the functions parameters into the three registers c,d,b... which source file should I read to understand?
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3769
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Tue Aug 08, 2017 10:08 am
sverx wrote
meta-sprite functions are IMHO beyond the scope of devkiSMS/SMSlib [...]


I thought that it might anyway be interesting to have a single function to place two sprites side by side, for instance to create a 16x16 'object' made of two 8x16 sprites, using tiles 'n' to 'n+3', as this is a very very common occurrence IMHO.

But I think that the function should also work with 8x8 sprites, and with zoomed sprites too, which brings me to the point that there should probably be 4 separate z80 asm functions 'behind' the same function name, using function pointers, updating the pointer to the correct function when calling SMS_setSpriteMode()... or simply have a function such as SMS_add16x16Sprite() which one will use only with 8x16 unzoomed sprites.

your opinion on this, guys?
  View user's profile Send private message Visit poster's website
Reply to topic Goto page Previous  1, 2, 3, 4  Next



Back to the top of this page

Back to SMS Power!