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 - Loading assets playing music

Reply to topic Goto page 1, 2  Next
Author Message
  • Joined: 28 Jan 2017
  • Posts: 541
  • Location: Málaga, Spain
Reply with quote
Loading assets playing music
Post Posted: Mon Aug 14, 2017 3:31 pm
Ummmm.... now i am finishing the alpha version of new game (screenshots soon) i have to fix this question...

Between scenes (with same music) i have to:
1. Load tiles and sprites (mandatory as each scene has a custom set of enemies so i have to load up to 140 sprites, the first 106 are for player)
2. Repaint initial view in screen of tilemap (the full screen 32x24 tiles)

As you think, the music gets frozen for one-two seconds.

Tryed to put some psgupdates in draw map function and between parts but it seems inconsistent.

Though on put psgupdate (for the full game) in line interrupt (around 192) but the game freeze this way. Cant understand why and if i can put the psg update for music into the vline interrupt callback function.

In other part, the smsaddsprite new func makes the game as fast with sdcc as it is with z88dk. Good work!

Any insight?
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 3759
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Tue Aug 15, 2017 10:57 am
If you can't break the asset loading into chunks that will surely take less than a single frame - for instance because you've got compressed data that you can't decompress in time - then your best option is surely to use line interrupt and update PSG within the line handler routine... but I advise you to do NOT use line 192 as it will somehow 'clash' into vBlank, and you don't need that. I suggest you use the 100th line, or the 120th for what is worth, so that the line handler will be complete by the time that vblank occours.
Of course in your line interrupt handler you've got to 'save' the current slot2 mapping, then map the bank where your music data is, call PSGFrame and after that map back the previous bank.
The easier way to check what's the currently mapped bank is to have a volatile unsigned char mapped at 0xffff and read from there as in
volatile __at (0xffff) unsigned char bank_currently_mapped_on_slot2;

so you just have to save this into a temporary variable
oldBank=bank_currently_mapped_on_slot2;

and later restore that as in:
SMS_mapROMBank(oldBank);

I hope this helps :)
  View user's profile Send private message Visit poster's website
  • Joined: 28 Jan 2017
  • Posts: 541
  • Location: Málaga, Spain
Reply with quote
Post Posted: Tue Aug 15, 2017 12:53 pm
That was te question! I suspected the bank has not to be the same as i had saved on my own functions. .. and not figured how to get the current bank mapped on slot 2.

...so things now work as expected. Thanks!
  View user's profile Send private message
  • Joined: 28 Jan 2017
  • Posts: 541
  • Location: Málaga, Spain
Reply with quote
Post Posted: Tue Aug 15, 2017 9:42 pm
Sorry to bother...

Why cannot i have the line handler in 192?

What should happen if the handler function reach to 0?

I have the function at 192 and everything goes nice.

Regards
  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14687
  • Location: London
Reply with quote
Post Posted: Tue Aug 15, 2017 10:06 pm
You want to reserve the VBlank time for VDP access, line interrupts near the bottom of the screen will eat into it.
  View user's profile Send private message Visit poster's website
  • Joined: 28 Jan 2017
  • Posts: 541
  • Location: Málaga, Spain
Reply with quote
Post Posted: Wed Aug 16, 2017 6:30 am
Yes, that makes sense.
But i use the 192 line interrupt to register i have painted the full screen and do a waitvblank to the next frame (if has passed, skip the waitvblank and begin to process next frame) this is done in a two frames basis and is important to archieve good performance in astroforce and more, more, more important in this platformer (where have up to 8 bigger enemies with gravity and tilemap colision and there are more code involved as i is a platformer).

So the question would he... how to get two line handlers (one at 96 by example, for update psg , and other at 192 simply to increase a counter)

...although i have to say it funcs well now, but if can be better, it will.

Regards.
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 3759
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Wed Aug 16, 2017 8:27 am
I wouldn't really use line interrupt on line 192 - or around that - if not for a good cause. Anyway of course you can do whatever you prefer ( ;) ) and if you set line IRQ on line 96 it will get triggered twice if you don't expressly deactivate it in your handler function.

But if you just need to have you music playing while decompressing stuff to VRAM, just set a single line interrupt and keep on using the 'normal' SMS_waitForVBlank() for screen syncing - that's just easier :)
  View user's profile Send private message Visit poster's website
  • Joined: 01 Feb 2014
  • Posts: 844
Reply with quote
Post Posted: Wed Aug 16, 2017 4:01 pm
I've got a somewhat related question: If you use an interrupt to call the sound routines during data decompression, how do you prevent an interrupt to trigger in the middle of one of the double writes to the vdp, causing graphics corruption? That was always my problem when trying to achieve something along these lines.
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 3759
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Wed Aug 16, 2017 4:08 pm
devkitSMS is interrupt safe, no interrupt will happen between the two writes. But anyway you can do damage if your line interrupt handler messes with the VDP while you're decompressing, as the compressor will happily go on decompressing to VRAM whatever the address... :|
  View user's profile Send private message Visit poster's website
  • Joined: 28 Jan 2017
  • Posts: 541
  • Location: Málaga, Spain
Reply with quote
Post Posted: Wed Aug 16, 2017 4:41 pm
It has been in depth tested (in line 192, the 60 stages of the game) and it works without trouble, at least in emulicious with vdp constraints.
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 3759
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Thu Aug 17, 2017 7:47 am
Happy to know that! :D
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14687
  • Location: London
Reply with quote
Post Posted: Thu Aug 17, 2017 9:11 am
I'm guessing that you are using the "safe" functions for loading all your graphics, which is why you can not care so much about the VBlank time - you are not taking advantage of it. The downside is that your data loading takes a long time - 1-2s is actually quite slow.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3759
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Thu Aug 17, 2017 9:38 am
'unsafe' functions are surely faster to upload data to VRAM as they use a block of OUTI opcodes, and these could even be used when NOT in vBlank just turning off the screen, but I believe the point here is that he's decompressing to VRAM from some compressed format... there are no 'unsafe' decompression functions in devkitSMS/SMSlib as they would be pretty much useless, in term of speed gain.

edit: now I'm curious to know how much data / which compression scheme you're using, eruiz00 :)
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14687
  • Location: London
Reply with quote
Post Posted: Thu Aug 17, 2017 10:42 am
If possible, it would be nice to decompress the data in advance to get faster uploads (minimise off time), kind of like streaming assets in modern games. This would be hard, though...
  View user's profile Send private message Visit poster's website
  • Joined: 28 Jan 2017
  • Posts: 541
  • Location: Málaga, Spain
Reply with quote
Post Posted: Thu Aug 17, 2017 12:16 pm
The ussual... psgcompr for tiles and sprites.

Though at first the culprit was the first screen map filling, which fills the screen from 16x16 tiles, from an uncompressed tilemap.

But after testing, it was (mainly) the tile decompression routine, which takes up to 224 tiles from a 16x640 image to decompress and put in vdp. Also has to load 32 chars for text, and the up to 256 sprites (they are in little pieces, some for player walking, cropping, jumping, flying, using a ladder, shooting... some for enemies) so the big chunk it is the background tiles one.


But it is safe and plays nicely now.
  View user's profile Send private message
  • Joined: 28 Jan 2017
  • Posts: 541
  • Location: Málaga, Spain
Reply with quote
Post Posted: Thu Aug 17, 2017 1:01 pm
Maxim, you said time ago about asttoforce that had too much code.

Maybe this new game im working, a platformer way more complex, has better coding and it depends more on data on banks. In fact, as i dont want to pass 256kb (i passed yet), im shrinking some things.

But the fact i have 6kb free for code... so i think it should not be difficult to have graphics predecompressed, using left time on frames with a counter and doing it on little chunks.
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 3759
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Thu Aug 17, 2017 1:55 pm
if you want to increase compression on some asset that doesn't compress enough, you can switch to aPlib which usually compresses way more.

Also, if your text is in fact using a single color, you might be interested to know that I'm almost releasing a function to load 1bpp tiles (and 32 1bbp tiles/chars would require 256 bytes only in your ROM)

edit: you can also put some assets in your spare space in the lower 32KB using assets2banks' "bank1size" feature.
  View user's profile Send private message Visit poster's website
  • Joined: 28 Jan 2017
  • Posts: 541
  • Location: Málaga, Spain
Reply with quote
Post Posted: Thu Aug 17, 2017 3:40 pm
Last edited by eruiz00 on Thu Aug 17, 2017 3:46 pm; edited 1 time in total
Umm... if i use aplib and get more space and after that i use the 1bpp function, and next i pass data to bank 1 and finally i get (lets say...) 20kb more for content.... better i shoot my feet.

Jokes appart, somedays i am so tired of so much work and things to do/fix/improve on this(on spare time) ... that even think on how would things be if i were to buy a wii u and stay all day playing last mario game :(

Will try aplib and (if it is on github) the new function ;)

Moreover, it is an enough long platformer (about 1 hour) but my problem is to have enough variety (gameplay variety) on different scenes that in make it more/less long. A gameplay refinement process more than content creation .
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 3759
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Thu Aug 17, 2017 3:43 pm
eruiz00 wrote
if i use aplib and get more space


First try compressing your data to see how much would you actually save... it may be worthy, but it also may be not. Also, keep in mind that aPlib is much slower, as it reads back from VRAM.

1bpp tiles function will be ready in a few days probably.
  View user's profile Send private message Visit poster's website
  • Joined: 17 Nov 2015
  • Posts: 97
  • Location: Canada
Reply with quote
Post Posted: Sat Aug 19, 2017 1:40 am
sverx wrote
eruiz00 wrote
if i use aplib and get more space


First try compressing your data to see how much would you actually save... it may be worthy, but it also may be not. Also, keep in mind that aPlib is much slower, as it reads back from VRAM.

1bpp tiles function will be ready in a few days probably.


You can also try zx7. Since you have z88dk installed, you also have zx7 present.

To compress a file just enter "zx7 foo.dat" or "zx7 -f foo.dat" to force overwriting an existing output file.

In the z88dk library there are both safe and unsafe functions for decompressing into vram.

See line 110:
https://github.com/z88dk/z88dk/blob/master/include/_DEVELOPMENT/sdcc/compress/zx...

The aplib decompressor is also available:
https://github.com/z88dk/z88dk/blob/master/include/_DEVELOPMENT/sdcc/compress/ap...

but it is the slow decompressor not the new fast one maxim wrote.
https://github.com/z88dk/z88dk/blob/master/libsrc/_DEVELOPMENT/compress/aplib/z8...
  View user's profile Send private message Visit poster's website
  • Joined: 28 Jan 2017
  • Posts: 541
  • Location: Málaga, Spain
Reply with quote
Line 192
Post Posted: Tue Aug 29, 2017 5:38 pm
Ummm...

Have to say that after deep emulicious testing i was wrong.

Updating music and sound at line 192 i obtain random tile update errors (noise) as it seems to pass vblank phase, so i changed to 180 and now it funcs well!
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 3759
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Tue Aug 29, 2017 7:48 pm
I would set it slightly before that, as music handling can occasionally take a little bit more than the scanlines you're currently allocating (12).
Everything between 100 and 160 should be safer and shouldn't have any side effect at all.
  View user's profile Send private message Visit poster's website
  • Joined: 28 Jan 2017
  • Posts: 541
  • Location: Málaga, Spain
Reply with quote
Post Posted: Tue Aug 29, 2017 8:17 pm
I am sure of that.

But i use that function also for register if i have redrawn all the screen and avoid waitvblank function. So i have to be cautious with that:(
  View user's profile Send private message
  • Joined: 28 Jan 2017
  • Posts: 541
  • Location: Málaga, Spain
Reply with quote
Post Posted: Tue Aug 29, 2017 8:30 pm
Btw sorry for have not senf the map files. Have been soooo busy (family wedding). Now i have compiled both sdcc and z88dk versions and have seen a 2300bytes difference (!!!). Lets see if i can send this map files.
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 3759
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Wed Aug 30, 2017 8:18 am
If you could compare the sizes of the functions from the two compilers it would be wonderful.
  View user's profile Send private message Visit poster's website
  • Joined: 28 Jan 2017
  • Posts: 541
  • Location: Málaga, Spain
Reply with quote
Post Posted: Wed Aug 30, 2017 8:32 pm
Here they are. Both have been compiled 10 mins ago, with recent versions of sdcc and z88dk.

Shame could not get how to calculate function sizes for the z88dk map file, as ot seems much more detailed.

The builds are the first in which the game gets alpha state. It is playable from init to end, although will be revised (mainly graphics) before launch. From that day , far now, 5 of may, can say i have finished other game (something which, you know, it is an very easy thing!).

More info soon.
cursedcastle-z88dk.7z (23.44 KB)

  View user's profile Send private message
  • Joined: 17 Nov 2015
  • Posts: 97
  • Location: Canada
Reply with quote
Post Posted: Thu Aug 31, 2017 3:13 am
eruiz00 wrote

Shame could not get how to calculate function sizes for the z88dk map file, as ot seems much more detailed.


The z88dk map file throws every single symbol in and it doesn't separate constants from addresses.

You may have more success by generating a public definitions file which will only include public symbols, like function names, and you can filter it further with a filter file containing regular expressions.

An example filter:

zfilter.txt

-^__
-IOCTL
-SP1V
-zx_01
-console_
+.*


The leading minus means reject and a leading plus means accept. Each symbol name will be compared against the regular expressions on each line in order and will be rejected or accepted if a match is found.

So this one will eliminate symbols with two leading underscores, symbols containing IOCTL, etc. The last line accepts any remaining symbols. You can look at the map file and try to eliminate / accept global symbols that you want out (global symbols are marked G in the map file).

Add this to the compile line making the binary:

-gf zfilter.txt

and out will come a foo.def file with a lot of symbol clutter removed. Maybe that will make it easier to locate the functions in sequential order minus their local labels.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3759
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Thu Aug 31, 2017 7:59 am
according to SDCC's map file, your code is just a few bytes too big to fit into 32 KB:
000080F7  l__CODE

I wonder if you can't shave those few bytes making a few functions more generalized so that you can use them for similar (but different) purposes - well, it's hard to tell just reading a map file :)

Also, I noticed that you're initializing quite a lot of variables:
00000298  l__INITIALIZED

I don't know if some of these global variables are initialized to zero: in case: don't do that! The internal RAM will be zero-ed out by the crt0 module before your main starts, so if you set global variable to zero it'll be just a waste of time and ROM space.

I hope this helps to shave a few bytes more. There are some other small tricks you can use, but as they save just a few bytes, they can be the last resort if you just can't find those last xx bytes of space... and I'll tell you about them just in that case ;)
  View user's profile Send private message Visit poster's website
  • Joined: 17 Nov 2015
  • Posts: 97
  • Location: Canada
Reply with quote
Post Posted: Thu Aug 31, 2017 8:23 am
Last edited by Alcoholics Anonymous on Thu Aug 31, 2017 2:44 pm; edited 1 time in total
sverx wrote
according to SDCC's map file, your code is just a few bytes too big to fit into 32 KB:
000080F7  l__CODE



I think he's over by 1800+ bytes. The code section starts at 0x200 so it's running to 0x82f7. But the code section is not the last section in the main rom. HOME, INITIALIZER, GSINIT, etc are also in there.

I can see in the HOME bank that mullong takes up 380 bytes. That's going to be substantially larger than z88dk's 32 bit multiply which will probably be about 60 bytes. That's one contributor anyway.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3759
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Thu Aug 31, 2017 9:10 am
oh, right. 0x2f7 bytes in CODE... and I've never seen HOME section in my tests... mullong? do you really need that? :|

About those 0x298 bytes in INITIALIZER, I bet some (many?) of them can be saved by removing zero assignment, as I said.

Quote
I think he's over by 1800+ bytes.


1803 if I accounted everything correctly this time :)

@eruiz00 IMHO you're using too many (different types of) divisions, modulus and multiplications:

       __divuint                         
       __divuchar                         
       __divu8                           
       __divu16                           
       __moduchar                         
       __moduint                         
       __mulint                           
       __mul16                           
       __modschar                         
       __modsint                         
       __divsint                         
       __divschar                         
       __div8                             
       __div_signexte                     
       __div16                           
       __get_remainder


maybe you just forgot some 'unsigned' before some variables declarations?
  View user's profile Send private message Visit poster's website
  • Joined: 28 Jan 2017
  • Posts: 541
  • Location: Málaga, Spain
Reply with quote
Post Posted: Thu Aug 31, 2017 9:47 am
Interesting....

The fact is that compilation includes minigame. It runs on Z88DK, but not in SDCC.

This night will try to shave these things. I saw long time ago that declare variables eats rom space. Seeying the data section on z88dk compilation too empty, could not understand.

I have unsigned ints for positions, and signed chars for speeds, so i suppose here are these mults/divs
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 3759
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Thu Aug 31, 2017 10:19 am
eruiz00 wrote
I have unsigned ints for positions, and signed chars for speeds, so i suppose here are these mults/divs


from what I see, you're performing both division and modulus on unsigned int, unsigned char, signed int and signed char, and that's 8 functions:

       __divuint                         
       __divuchar                         
       __divsint                         
       __divschar     
       __moduchar                         
       __moduint                         
       __modschar                         
       __modsint


and some other stuff beside these. I suggest you to review your code for division and modulus, you'll likely save ROM space and CPU time :)
  View user's profile Send private message Visit poster's website
  • Joined: 28 Jan 2017
  • Posts: 541
  • Location: Málaga, Spain
Reply with quote
Post Posted: Thu Aug 31, 2017 12:22 pm
Ummm... the game performs flawlessly so that is not a problem. Ill check for signed ints and initialized vars in code sections (although i am almost sure it should be one or two ints as much)...

The mullong is because the rand function, much faster the one included in sdcc.
  View user's profile Send private message
  • Joined: 28 Jan 2017
  • Posts: 541
  • Location: Málaga, Spain
Reply with quote
Post Posted: Thu Aug 31, 2017 12:32 pm
About generalized functions, i can assure that from the beggining was important for me. It is much deeper at this point that asyroforce was. Logical optimizations are no option. But.... hey! The game runs on both sdcc and z88dk. The only difference is that the minigame is not included on sdcc version (sent sdcc version with minigame so you can compare)
  View user's profile Send private message
  • Joined: 28 Jan 2017
  • Posts: 541
  • Location: Málaga, Spain
Reply with quote
Post Posted: Thu Aug 31, 2017 12:33 pm
Could send the minigame (a pacman clone) and see if someone gets fun doing a shorter version :)
  View user's profile Send private message
  • Joined: 17 Nov 2015
  • Posts: 97
  • Location: Canada
Reply with quote
Post Posted: Thu Aug 31, 2017 3:03 pm
eruiz00 wrote

This night will try to shave these things. I saw long time ago that declare variables eats rom space. Seeing the data section on z88dk compilation too empty, could not understand.


The data section must be stored in rom so that it can be copied into ram at startup. The total size is 908 bytes according to your map file and the size should be almost the same in sdcc and z88dk compiles, with any difference due to library functions if they use data. z88dk emits the data section as a separate file "foo_DATA.bin" after a compile so you can see its size there.

But z88dk can store the data section in compressed form so if you're doing that by setting CRT_MODEL=2 you might see a smaller data section in rom.

Quote

I have unsigned ints for positions, and signed chars for speeds, so i suppose here are these mults/divs


If you can get rid of signed mult / div that also helps in speed. For signed divisions, the correct sign of the quotient and remainder has to be determined in an extra step (although I think sdcc completely separates / and % whereas z88dk does them both in one / since both are computed as part of the algorithm). And for signed mult and signed div, there may be sign extension code to increase the bit width of one operand to match the other.

But for 16-bits and below, sdcc's integer math is implemented in asm and the size penalty of having these extra variations shouldn't be too large, although you may save up to a hundred bytes in worst case:

https://sourceforge.net/p/sdcc/code/HEAD/tree/trunk/sdcc/device/lib/z80/

Quote

The mullong is because the rand function, much faster the one included in sdcc.


The sdcc rand function has been updated to a marsaglia xor generator which is based on shifts and xor so it should be much faster now and certainly faster than a 32-bit multiply:

https://sourceforge.net/p/sdcc/code/HEAD/tree/trunk/sdcc/device/lib/rand.c

z88dk does the same but with different triple:

https://github.com/z88dk/z88dk/blob/master/libsrc/_DEVELOPMENT/stdlib/z80/random...
  View user's profile Send private message Visit poster's website
  • Joined: 28 Jan 2017
  • Posts: 541
  • Location: Málaga, Spain
Reply with quote
Post Posted: Thu Aug 31, 2017 7:24 pm
Ummmm... i am sure (notepad++ had nice search tools) i have not "signed int" neither "int" on code. (Only "unsigned ints", "signed chars", and "unsigned chars")

But i have the div and modulus signed functions for int. Lets see....

1. These functions are in same .o file as unsignef ones and they come into rom yes or yes?

2. Sone function signed char parameter is calculated in the call to the function (inline) using unsigned ints?

3. In smslib.h there are functions with signed ints (those of sprite clipping, although i dont use them)?

Btw, removing my rand saves bytes, yes!
  View user's profile Send private message
  • Joined: 28 Jan 2017
  • Posts: 541
  • Location: Málaga, Spain
Reply with quote
Post Posted: Thu Aug 31, 2017 9:25 pm
Oh my god! Never though sdcc could not think that sum is unsigned (both vars are unsigned chars)...... have 6-8 in my asm code!!!
20170831_232310.jpg (2.95 MB)
20170831_232310.jpg

  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 3759
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Fri Sep 01, 2017 9:14 am
eruiz00 wrote
In smslib.h there are functions with signed ints (those of sprite clipping, although i dont use them)


if you don't use sprite clipping functions, they won't end up taking space in your code (I mean their module won't be linked in at run time)

Also, I just updated devkitSMS crt0 code, reordering the startup stuff a bit, so that I left a 150 bytes contiguous space at the end of it.

To reclaim those bytes for your program you have to add
--code-loc 0x16A

to your linker invocation such as
sdcc -o output.ihx -mz80 --code-loc 0x16A --data-loc 0xC000 ....

of course ONLY after having updated your crt0_sms.rel

Let's shave each and every byte until we can make that fit with SDCC! :D
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3759
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Fri Sep 01, 2017 9:19 am
eruiz00 wrote
Oh my god! Never though sdcc could not think that sum is unsigned (both vars are unsigned chars)...... have 6-8 in my asm code!!!


I'm using this macro:
#define UCHAR(x)     ((unsigned char)(x))

so you can do:
SMS_setNextTileatXY (z,UCHAR(maptileposy+r)%28);

btw, setNextTileatXY is just the same that setAddr(XYtoADDR()) and much more readable :)
  View user's profile Send private message Visit poster's website
  • Joined: 28 Jan 2017
  • Posts: 541
  • Location: Málaga, Spain
Reply with quote
Post Posted: Sat Sep 02, 2017 9:49 am
Ummmm....

Shaving this weekend
  View user's profile Send private message
  • Joined: 28 Jan 2017
  • Posts: 541
  • Location: Málaga, Spain
Reply with quote
Post Posted: Sat Sep 02, 2017 11:31 am
One interesting question is howto sdcc gets broken again in last week versions(around) even those with rt passed, while z88dk funcs well... i refer about simple funcs in which signed/unsigned or char/int is determinant to solve the break. And about inconsistency in code generated.
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 3759
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Sat Sep 02, 2017 12:23 pm
I guess the problem comes from the reason that when the code doesn't fit into the first 32KB, what will be placed into next page will be overwritten by bank2's data. SEGA header will also overwrite your code at 0x7FF0. There's nothing you can do about that, you just have to code within the limits, trying every dirty trick to do that, sometimes.
  View user's profile Send private message Visit poster's website
  • Joined: 28 Jan 2017
  • Posts: 541
  • Location: Málaga, Spain
Reply with quote
Post Posted: Sat Sep 02, 2017 3:13 pm
Ummmmm.... i am not speaking of code size.

I am speaking about broken loops and comparisions in generated code between sdcc versions.

By example, astroforce writenumber function, which is a simple loop writing tiles, compiles well under 27-7 and 12-8 and 22-8 versions, but doesnt under 5-8, 1-9 versions (i save that versions because i dont trust new updates before try)

In z88dk i see same problems (logical) but the last trouble i found was beggining of august.

Thats why, although i regularly update and test with z88dk, i stick with 27-7 sdcc. Whit that i compile both astroforce and cursedcastle without running troubles.
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 3759
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Sat Sep 02, 2017 9:17 pm
yes, unfortunately SDCC has currently a few pesky bugs, so it happens to me too that I have to work around them, in some way.
If you find some bug, please check if it's already filed here, if it's not then create a new ticket.
currently there are problems with accessing short arrays and a few very annoying others. they'll be hopefully fixed before next official release.
  View user's profile Send private message Visit poster's website
  • Joined: 17 Nov 2015
  • Posts: 97
  • Location: Canada
Reply with quote
Post Posted: Sun Sep 03, 2017 7:12 pm
eruiz00 wrote
Oh my god! Never though sdcc could not think that sum is unsigned (both vars are unsigned chars)...... have 6-8 in my asm code!!!


One side of the mod is unsigned char and the other is signed int (28) so the unsigned char has to be promoted to signed int according to c rules. So it's right - you just have to be aware of that.

Quote

I am speaking about broken loops and comparisions in generated code between sdcc versions.


sdcc is not standing still - there have been several changes to the z80 code generator in recent months. These are introducing bugs - z88dk is staying at 9958 for now because bugs have been found by others in versions after this. I haven't had time to go through generated code yet to find out what they are and report them to sdcc / fix them. It's not easy to find them when you're only handed a large chunk of code :) Usually, given little info, I scan the generated asm and look for anything that looks fishy. On the one hand there can be a lot of code and it can be easy to miss errors, but on the other hand you also get a chance to identify and try to correct poor code generation in a real example.

The regression tests cover a lot but they aren't covering every possible use-case.

Quote

In z88dk i see same problems (logical) but the last trouble i found was beggining of august.


I expect it to be quite reliable but if you find any more let me know!
  View user's profile Send private message Visit poster's website
  • Joined: 28 Jan 2017
  • Posts: 541
  • Location: Málaga, Spain
Reply with quote
Shaving results
Post Posted: Mon Sep 04, 2017 5:44 am
Ummmmmm...

This weekend have switched to a z88dk-gnu make scheme, and split the code into more, smaller, more classified src files, and its great! For single file changes the compile process is so fast i could not believe.

Btw, shaving process has heen a success. Now i have done new nice new effects like fade in-out in scenes and dynamic text printing. Everything looks far more polished. Even with this changes, i have now 1200 bytes for code and 8kb in banks so time to improve!
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 3759
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Mon Sep 04, 2017 8:43 am
eruiz00 wrote
i have now 1200 bytes for code and 8kb in banks


you're doing a great work! :)
  View user's profile Send private message Visit poster's website
  • Joined: 28 Jan 2017
  • Posts: 541
  • Location: Málaga, Spain
Reply with quote
Post Posted: Tue Sep 05, 2017 12:19 pm
Ummm....

A suggestion. If the assets2bank utility could check if each file it writes (.c or .h) is equal to the existing one (if exists) and discard the rewrite, would be great for a make based system, as it woulf make unnecesary to recompile all the bank files.

The reason is the ussual is to do minor modification on a single map and test, and this does not change the resource file size, so assets2bank should not change the packing order, so ig only changes a bank, instead all banks.
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 3759
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Tue Sep 05, 2017 12:50 pm
actually some time ago I was thinking about making assets2banks directly generate .rel files, which would make things easier (you won't have to compile assets files) and that would also solve your problem.

But I need to spend some time researching the .rel format, which I don't know yet, so I can't make any promise.

edit: rel format isn't so complicated, new feature is on the way :)
  View user's profile Send private message Visit poster's website
Reply to topic Goto page 1, 2  Next



Back to the top of this page

Back to SMS Power!