Code Monkey home page Code Monkey logo

Comments (4)

jsmolina avatar jsmolina commented on May 26, 2024

The crash branch has about 3970 bytes available for sprites. I tried adding more memory by reducing the expected size of the stack to 256 bytes by adding this pragma to zpragma.inc:

#pragma output CRT_STACK_SIZE = 256

The default is 512 bytes reserved for the stack and that's very large. 256 bytes is even big and maybe could be made smaller. Anyway, the game seems to run fine with this increase of 256 bytes in the heap.

You can also try moving the org down lower in memory to create more space.

from speccy-misifu.

jsmolina avatar jsmolina commented on May 26, 2024

Adding test code is ok for finding the problem, otherwise it just adds to the code size; you want to make sure the game always has sufficient memory otherwise it can't run anyway, test code or not.

3970 bytes seems to be too small. You can do a calculation to figure out how much space from the heap each sprite requires:
https://github.com/z88dk/z88dk/blob/mas … /sp1.h#L56

  1. struct sp1_ss : 20 bytes + 4(?) malloc overhead
  2. Per character square a struct sp1_cs: 24 + 4(?) malloc overhead

So a 3 rows x 5 cols sprite would use up about:

24 + 15*(24+4) = 444 bytes

With 3970 bytes free, that adds up quickly!

If you want to create all sprites at the beginning and have them the whole game, your only option is to get more memory. So reduce the amount allocated to the stack, drop crt org, and/or move the ay stuff to a 128k memory bank. The latter is probably the easiest especially if the game is going to grow.

If you want to change it so that you allocate and destroy sprites as needed, you can calculate how much the worst case memory demand is and then use the block memory allocator to avoid fragmentation issues connected to a heap. What you can do is create a single queue that dispenses 24-byte blocks and redefine malloc to allocate from that queue and free to call the block allocator free function. To initialize, you would add available memory to the block queue. The nice thing about it is these blocks can come from all over the memory space, including that 208-byte hole at 0xd001 shown in the sp1 memory map. Then you can create and destroy sprites between levels as needed.

from speccy-misifu.

jsmolina avatar jsmolina commented on May 26, 2024

I think I calculate about 4560 bytes required from the add_sprites_for_all_levels() function in defines.c. So there are probably still problems with the compile that runs with stack size 256 bytes.

There are a few more things you can do. The clothes sprites, if they are always at the bottom priority and displayed on blank tiles, could be changed to 1-byte LOAD sprites. This will reduce the size of the associated graphics (and make them faster to draw).

A much bigger impact is if you always draw sprites at multiples of 4 pixels (or other multiples) then you can reclaim some of the memory used by sp1 for rotation tables. sp1's rotation tables at 0xf200-0xffff are table lookups for 1,2,3,4,5,6,7 pixel rotations and if you only use 4 in that list, you can take back the memory for the others. The block memory allocator can be given this memory quite easily.

Lastly you could consider printing background tiles for background elements like the clothes instead of using sprites.

from speccy-misifu.

jsmolina avatar jsmolina commented on May 26, 2024

Just in case, if you do want to move the ay-related stuff into a 128k bank, as alvin said, you'd have lots of stuff to do too. You'd have to make sure that your interrupt table, which is likely to be at d000 - d100 for now, to move to a place between 32768 - 49151 (decimal), to ensure non-snowing on the real 128k+ machines.

What I usually do when I make a game with z88dk, is to reuse the created sprites to save memory. You can reused created sprites by changing its pointer, as long as they have the same dimensions. For example, if all your sprites are of 5x3 size, then you can swap the one with the other without allocating more memory for them. Then you create, during initialisation, all the sprites you need and then reuse them. When not in use, you just hide them.

For example, if your main screen (with the clotheslines) have a max of 8 sprites, then create those at the start of your game, and reuse these sprites in later levels as spiders or brooms. This way it saves you a lot of allocating memory. The dogs' eyes, the moving clothing and other small stuff that don't need to be sprites, you can use tiles for those.

from speccy-misifu.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.