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 - General Scroll Library (GSLib)

Reply to topic Goto page Previous  1, 2
Author Message
  • Joined: 01 Jan 2014
  • Posts: 331
Reply with quote
Post Posted: Mon Feb 26, 2018 3:43 am
Hi,

I got a chance to get back to this and checked notes, the above issue regarding column 0 being incorrect is intended. You want left most column hidden even on vertically scrolling games so you can scroll sprites on/off screen without them popping in to view.
  View user's profile Send private message
  • Joined: 01 Jan 2014
  • Posts: 331
Reply with quote
Post Posted: Mon Feb 26, 2018 3:47 am
A few minor updates.

    - Several bug fixes for UGT.
    - GUI Batch export option added for UGT. Export > Batch Export to GSLib.
    - Command line support added for batch processing.


Command line options support working with either tiled or image file.

tiled file
java -jar ugt.jar -tiledfile “C:\game\resources\jungle.tmx” -destination “C:\game\assets” -name stage1


image file
java -jar ugt.jar -imagefile “C:\game\resources\jungle.png” -destination “C:\game\assets” -name stage1


both produce 4 files at the supplied address; stage1_scrolltable.bin, stage1_metatiles.bin, stage1_tiles.bin, stage1_palette.bin


UGT is still not great. I highly recommend generating your own parsing tools tailored to your own game. You can find the scrolltable and metatile format in documentation provided with library. There is something better in the pipeline, hope to have more info soon.

Psidum
  View user's profile Send private message
  • Joined: 28 Jan 2017
  • Posts: 390
  • Location: Málaga, Spain
Reply with quote
Post Posted: Mon Feb 26, 2018 6:35 am
Hi!

Some questions as i am planning to test the lib replacing my own engine for yours one, mainly to testing speed.

Have you tested It on z88dk?
What RAM use overhead It has?

Regards

Edit: ok i answer myself reading the docs. Lets try this week. I Will need to make my own Converter as i need Groups of tiles to be adjacent , in order to update them with less calls.

Regards
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 2859
Reply with quote
Post Posted: Wed Mar 07, 2018 1:46 pm
@psidum: is there any chance for an additional UGT feature to load Mappy's fmp file? (file format is here - in readme.txt)
I would like to avoid having to build a converter from Mappy to Tiled format...
  View user's profile Send private message Visit poster's website
  • Joined: 01 Jan 2014
  • Posts: 331
Reply with quote
Post Posted: Thu Mar 08, 2018 7:32 am
I remember looking at this format before and getting confused. Will give it another go this weekend.

Having a quick look it would probably be best to directly parse to scrolltable and metatiles. Also are you using any of the user bits or collision bits?
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 2859
Reply with quote
Post Posted: Thu Mar 08, 2018 9:12 am
I don't think I'll use those bits.
Anyway I was wondering if GSLib handles maps which are smaller than the screen in one of the two dimensions -for instance a 'tall' map where the width is 15 metatiles only (30 tiles)- o it should be 16x12 minimum?
  View user's profile Send private message Visit poster's website
  • Joined: 01 Jan 2014
  • Posts: 331
Reply with quote
Post Posted: Fri Mar 09, 2018 2:21 pm
16x12 is the minimum for 1.0.

I plan to add support for the row and column locking in next version as well a few other things. Will do a write up about it shortly.
  View user's profile Send private message
  • Joined: 01 Jan 2014
  • Posts: 331
Reply with quote
Post Posted: Sun Mar 11, 2018 7:21 am
Sorry I can't do the mappy parser at the moment. I am rewriting some stuff on the tool side and will try to add it in but this won't be completed for a while yet.
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 2859
Reply with quote
Post Posted: Sun Mar 11, 2018 12:18 pm
don't worry - I was just exploring the feasibility of porting an existing game. No rush :)
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 2859
Reply with quote
Post Posted: Fri Jun 08, 2018 11:13 am
Last edited by sverx on Fri Jun 08, 2018 12:03 pm; edited 1 time in total
I've got a few questions about the library - if you psidum might shed some light for me :)

- What are the theoretical limits for the map size?
- How many different metatile can we have? (256 I guess...)
and finally
- Is it feasible to use it for just a section of the whole screen height? (imagine an horizontally scrolling game that has an HUD at the top and/or at the bottom of screen, which I'll keep at Hscroll=0...)

Thanks :)
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 13547
  • Location: London
Reply with quote
Post Posted: Fri Jun 08, 2018 11:52 am
You can't do HUDs and vertical scrolling at the same time. Any split scroll HUD has to be paired with single direction scrolling, unless you do some cunning tricks.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 2859
Reply with quote
Post Posted: Fri Jun 08, 2018 12:04 pm
I rephrased, because I meant to only scroll horizontally in that case - thanks!
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 13547
  • Location: London
Reply with quote
Post Posted: Fri Jun 08, 2018 12:12 pm
I suspect horizontal only ought to be a special case, not using a general two dimensional library... Then again, there are some games doing 2D scrolling with a HUD by scrolling by 8px vertically, which is another special case.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 2859
Reply with quote
Post Posted: Mon Jun 11, 2018 7:58 am
Indeed for horizontal scroll only I could write my own routines, but I'm lazy and psidum's lib is very good and fast thus if I can use that so much the better :D
  View user's profile Send private message Visit poster's website
  • Joined: 28 May 2015
  • Posts: 118
Reply with quote
Post Posted: Tue Jun 19, 2018 11:09 pm
How do you change priority of a tile using this library?
  View user's profile Send private message
  • Joined: 08 Sep 2018
  • Posts: 253
Reply with quote
Post Posted: Sat Sep 08, 2018 4:57 am
This actually saved one of my projects that I was debating on killing. I wish the collider stuff was ready, but I think I can at least handle that myself.
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 16
Reply with quote
Post Posted: Tue Nov 06, 2018 9:41 am
Maxim wrote
You can't do HUDs and vertical scrolling at the same time. Any split scroll HUD has to be paired with single direction scrolling, unless you do some cunning tricks.


So for example it would not be possible to do Gauntlet or Cool Spot (the versions of Master System I mean) like split screen with the library? How do those games perform that split screen effect?
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 2859
Reply with quote
Post Posted: Tue Nov 06, 2018 10:42 am
I would say Cool Spot is swapping the current tilemap at midscreen [*], pointing to a completely empty one (tiles with only a plain background color) and over that background they use only sprites to 'build' the HUD.

[*] or the same tilemap, and they set plain tiles only at these locations.
  View user's profile Send private message Visit poster's website
  • Joined: 29 Mar 2012
  • Posts: 656
  • Location: Spain
Reply with quote
Post Posted: Thu Dec 12, 2019 1:12 pm
Resurrecting this topic to say that I'm using the library for the devkitSMS tutorial I'm doing at elotrolado.net:

https://www.elotrolado.net/wiki/DevkitSMSTutorial
(Sorry, only spanish)

And the code is being uploaded here:

https://github.com/kusfo/shootertutorial

And I'm using the marvelous assets that surt has at OpenArt, with these great results:

B6CE4800-CB99-44BD-BDF4-8D04639B0BBF.png (108.93 KB)
Attachment fairy
B6CE4800-CB99-44BD-BDF4-8D04639B0BBF.png

  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 2859
Reply with quote
Post Posted: Fri Dec 13, 2019 10:08 am
@kusfo: image doesn't show up (deeplinking blocked by elotrolado.net, please attach it!)
  View user's profile Send private message Visit poster's website
  • Joined: 29 Mar 2012
  • Posts: 656
  • Location: Spain
Reply with quote
Post Posted: Fri Dec 13, 2019 10:37 am
wow! I think that maxim has already attached it
  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 13547
  • Location: London
Reply with quote
Post Posted: Fri Dec 13, 2019 12:14 pm
No, it was the attachment fairy. Nothing to do with me...
  View user's profile Send private message Visit poster's website
  • Joined: 29 Mar 2012
  • Posts: 656
  • Location: Spain
Reply with quote
Post Posted: Fri Dec 13, 2019 12:57 pm
So the attachment fairy is real!? :-O
  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 13547
  • Location: London
Reply with quote
Post Posted: Fri Dec 13, 2019 1:08 pm
Yes, she fixes up the attachments and then comes and takes a tooth from the person who forgot to attach the file, while they are sleeping...
  View user's profile Send private message Visit poster's website
  • Joined: 08 Sep 2018
  • Posts: 253
Reply with quote
Post Posted: Thu Jan 21, 2021 6:23 pm
Note to anyone wanting to use this library.

Its kind of tight on timings. It should be the very first task you execute on VBlank before doing other things such as PSG Updates or I/O port operations.
If you have a "dual threaded" task based system where you exx and ex AF,AF' on the interrupt to give the interrupt its own register set to work with then the following is very important.
This library destroys that paradigm since it requires both register sets to operate during its VBlank routine. Protect thyself! Since it happens during VBlank, you may need a different method of preserving your registers when the unexpected jump occurs.
Some thoughts Ive had about it is pushing important registers on the stack and popping them when you finish your VBlank work. Saving registers to a fixed cache in ram is also an option... but these operations can be kind of slow compared to exx so keep that in mind. Obviously tutorials here suggest just pushing and popping AF which is a quick and safe option. I suggest storing HL as well since it and AF will most likely be the most used during active screen operations.
Lastly, the provided example Demo with the library makes a decent template to follow. It tells you when and where things should be called as well as what is required for them. Stick to that order or GSL will not work well for you at all.
  View user's profile Send private message
  • Joined: 01 Jan 2014
  • Posts: 331
Reply with quote
Post Posted: Fri Jan 22, 2021 3:46 am
Thanks for the feedback 😊
The points you make a largely true…

IllusionOfMana wrote
Note to anyone wanting to use this library.

Its kind of tight on timings. It should be the very first task you execute on VBlank before doing other things such as PSG Updates or I/O port operations.


The VBlank code is optimized (at the expense of the active display routine) but still it takes time. This is largely due to horizontal scroll requirements and the need to calculate and reset the VDP’s internal pointer for each entry in the column update.

On a side note, this was bothersome enough that SEGA added functionality in the MegaDrive to address this.

- The MegaDrive VDP internal pointer no longer increments at a fixed rate, instead it increments by an amount specified by the user in the AutoIncrement register.
- The 68K/VDP combo can send updated to VRAM in bytes, words or longwords!

With these two features the coder can update each nametable entry with a single word write and have the autoincrement register push the pointer to the next entry in the column, from the coder’s perspective the update is a simple linear stream of data much like the simpler vertical update.

For us SMS coders it is just something we need to deal with.


IllusionOfMana wrote

If you have a "dual threaded" task based system where you exx and ex AF,AF' on the interrupt to give the interrupt its own register set to work with then the following is very important.
This library destroys that paradigm since it requires both register sets to operate during its VBlank routine. Protect thyself! Since it happens during VBlank, you may need a different method of preserving your registers when the unexpected jump occurs.


This is true, the library destroys shadow registers. It is a genuine debate if it should.

- One perspective: the design philosophy behind shadow registers was that these should be remain unused in general code so they could be relied upon for speedy interrupt routines.
- The other perspective: optimal usage of the z80 involved maximising usage of registers including shadow registers. To quote someone more knowledgeable on the subject “Even the earliest of the earliest games I've looked into use the shadow registers in their plain code”.

It is a bit of a grey area in general however given games can benefit strongly from speedy interrupts I am inclined to agree, it should not have used the shadow registers and the next version (should it ever make it out) will hopefully address this speaking of which…
  View user's profile Send private message
  • Joined: 01 Jan 2014
  • Posts: 331
Reply with quote
Post Posted: Fri Jan 22, 2021 4:13 am
The subject of scrolling and retro game engines has been a fascination of mine for some time. Three years ago I decided to put my ideas in to practice and GSLib was coded.

In retrospect I consider this library a failure. The scrolling code is acceptable however it is incredibly difficult to integrate into the broader aspects of a game.

The last 2 years I have given thought to this project and largely gone back to the drawing board.

On the z80 side I have been looking at a broad range of scrolling solutions from the earliest ones with focus on minimum ROM/RAM usage to more ambitious engines typically seen in later 16bit games. Designing a range of solutions, implementing them, then watching them crash and burn against the brutal realities of 8bit hardware, it has been insightful and humbling.

At this point if the fix for GSlib was some improved z80 scrolling code I could spit some out tomorrow and be done with it. Unfortunately, the bigger and far more complicated problem is this integration problem which consists of many issues the major ones being…

- Making an engine that has general application.
- Has a level format that is not just graphics but a container for a broader range of gameplay related information including but not limited to…
    * Custom entities (enemies, triggers, etc).
    * Custom tile/metatile information (spikes, lava, solid, exit, etc).
- Z80 code that exposes the above information in a general and practical way, giving users flexibility to mold the scroll engine around their game rather than being forced to mold their game around the scroll engine.


There is also the problem of how to expose this functionality to users. What use is support for custom entities and tile/metatile information if the process of embedding this information is unworkable.

So, what is the status of GSlib 2.0? Z80 stuff is largely sorted. The new map format with embedded game elements has been tested and works nicely. The problem is exposing all this functionality to the user, but I think I finally have my solution. I am working towards and will have a better idea soon. It is going to take some time though.

There is obviously a lot more to it, a lot of smaller nuanced stuff but I have kept to the core points for brevity. When it becomes clear everything will work, I will probably do a write up. I would be curious to know people’s thoughts.
  View user's profile Send private message
  • Joined: 08 Sep 2018
  • Posts: 253
Reply with quote
Post Posted: Fri Jan 22, 2021 6:21 am
Last edited by IllusionOfMana on Fri Jan 22, 2021 6:15 pm; edited 1 time in total
Quote

Thanks for the feedback 😊
The points you make a largely true…


Personally I think what you've done with GSL is amazing. Prior to it I know I was stuck on tackling the task of scrolling with one of my z80 projects. Using GSL to help solve this was a huge weight off of any z80 project aiming for large more open worlds. I know when I first fully implemented it into my old project and it worked it was very exciting and got me interested in my projects again.

Now that I am trying to make a Sega Master System programming tutorial, I am stepping through how things should be set up for the system. I am also walking through libraries like PSG Lib and GSL with plans to show how to set them up and run them. That's ultimately what lead me to my note earlier.

I found that GSL 1.0 really likes things a certain way in order to work nice with a given system setup. I wrote my note on it in the hopes of helping others solve problems and not give up on the library when things got tough (or weird).

At the end of the day, the Master System is always going to be a bit hard to work with due to the VDP and the size of the bus. But I think that's all part of the fun!

If you do update GSL, then that's fantastic and I cant wait to see it!
If not/never then either way thanks so much for creating such a helpful library!
  View user's profile Send private message
  • Joined: 29 Mar 2012
  • Posts: 656
  • Location: Spain
Reply with quote
Post Posted: Fri Jan 22, 2021 9:58 am
I also think GSLib is great! I've used it on some concept demos, and I plan to use it soon on a game :-)
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 2859
Reply with quote
Post Posted: Fri Jan 22, 2021 11:24 am
I greatly prefer libraries that do one single thing and do that well, and the existing GSlib does exactly what it says.

As for the shadow registers topic... I came to the conclusion that shadow registers are such an invaluable resource when it comes to some extreme kind of optimizations that it's a waste to use them just for quick interrupt handling, so whenever I code interrupt handlers I always prefer pushing (the smallest amount possible of) registers onto stack, and pop them back when done.

On the other hand of course if your 'regular' code never uses them, that's when you can actually reserve them for IRQ handling, keeping in mind that interrupts can be made interrupt-able (and NMI can interrupt anyway) so caution is needed.

Also, sometimes I think the SP register is another of those invaluable resources we usually don't use to the fullest. Some code performing a memset of a constant-evenly-sized area would be way faster abusing the SP register and PUSH opcode than using any other way I can think of. (but NMI sucks!)
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 13547
  • Location: London
Reply with quote
Post Posted: Fri Jan 22, 2021 12:40 pm
I think that sometimes you need that register space for an optimal algorithm, but if you want to use line interrupts then it’s really valuable to minimise the time taken to preserve state. It’s not simple to select one over the other. Having an interrupt handler that pushes all of the registers and all of the shadow registers is burning a lot of time for a line interrupt.

If only they’d mapped the reset button to NMI and the pause button to a controller register...
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 2859
Reply with quote
Post Posted: Fri Jan 22, 2021 10:45 pm
Maxim wrote
Having an interrupt handler that pushes all of the registers and all of the shadow registers is burning a lot of time for a line interrupt.


I think an interrupt service routine should only save the registers it's going to use. And if you do use all the registers in your interrupt service routine and want to reserve the shadows registers for that, then you can't use them anywhere else.

... or you need to enclose the part of code that uses them in DI/EI pairs, which means that you have to make sure that part of code won't run when the interrupt can happen, or your interrupt may be serviced (too) late.

As often, it's all about choosing the best option for your case.
  View user's profile Send private message Visit poster's website
  • Joined: 26 Jul 2020
  • Posts: 7
Reply with quote
Wrapping scroll library
Post Posted: Wed Jan 27, 2021 5:51 pm
I have a project that needs to scroll a 160x140 tilemap, with horizontal and vertical wrapping. This may be a bit optimistic of me, but I thought I'd check here if wrapping is something that's in development, or if there are any other options I may have missed?

I know it would add a lot of complexity to GSLib, so please don't take this as a request if you're not already considering it. Thanks!
  View user's profile Send private message
  • Joined: 08 Sep 2018
  • Posts: 253
Reply with quote
Post Posted: Wed Jan 27, 2021 6:27 pm
MrBurrito wrote
I have a project that needs to scroll a 160x140 tilemap...


That's pretty small so technically it'll already wrap just with the native scroll hardware in the VDP.
If you're trying to get a seamless wrap without borders in GSL 1.0 then you can always duplicate your map into a large 3x3 scroll able map and use scroll position triggers to jump back at a specific position to simulate seamless wrapping. It'll cost you some extra rom space but will still work.
  View user's profile Send private message
  • Joined: 26 Jul 2020
  • Posts: 7
Reply with quote
Post Posted: Wed Jan 27, 2021 6:55 pm
I thought that it was too big to have multiple copies, but maybe with the compression... Also I think it would only need 2x2 copies for that trick to work. Will have to be careful not to draw the whole screen when doing the big jump, but I'll give it a go, thank you.
  View user's profile Send private message
  • Joined: 08 Sep 2018
  • Posts: 253
Reply with quote
Post Posted: Wed Jan 27, 2021 7:28 pm
I've successfully pushed 1280x1080 pixel maps through GSL 1.0 before so I think you are safe. I think it uses a 16 bit size values for the map so 65536x65536 pixel maps are the absolute max? I could be wrong on those numbers but either way I know it can do large maps.

EDIT: I just realized you were talking about size in tiles and not pixels. My bad yeah that is a big map!

In that case you dont need to duplicate your map 2x you just need a screens worth duplicated on each side and scroll jumps. That should keep your map size close to the original and accomplish your goal.
  View user's profile Send private message
  • Joined: 26 Jul 2020
  • Posts: 7
Reply with quote
Post Posted: Wed Jan 27, 2021 8:46 pm
160 tiles are exactly 1280 pixels, so we're in the right ballpark. Of course, you're right about only needing a screen worth of padding. Uncompressed, that would take me over the 32KB I can fit in banks 2 and 3, but with GSLib it seems feasible. Brilliant, thanks for your help.
  View user's profile Send private message
  • Joined: 08 Sep 2018
  • Posts: 253
Reply with quote
Post Posted: Wed Jan 27, 2021 8:59 pm
Of course, good luck! Hope to see the results! Once again, sorry for the confusion earlier.
  View user's profile Send private message
  • Joined: 01 Jan 2014
  • Posts: 331
Reply with quote
Post Posted: Sat Jan 30, 2021 1:18 am
IllusionOfMana wrote
I think it uses a 16 bit size values for the map so 65536x65536 pixel maps are the absolute max?


From memory this is correct.

Metatiles :are limited to 256 entries and are 4xnametable entries so 256*8 is 2048 bytes max size there.

ScrollMap: is constructed from metatiles with a one byte index representing 4 tiles/nametable entries so given 16bit pixel dimensions the max size in tiles is 8192x8192, the theoretical max size of a map is (8192x8192) / 4 = 16,777,216 bytes!

So there are various constraints but the biggest for sure is the size of ScrollMap scaling badly with map size.

This is the type of subject i was eluding too when talking about reviewing and implementing different scrolling solutions. There are solutions out that scale way better than the one implemented in this library but like everything they have their own strengths ans weaknesses.

It is interesting that when we talk about this subject we tend to talk about the act of scrolling but the real question is what is the underlying data format because it is what defines how everything works.
  View user's profile Send private message
  • Joined: 26 Jul 2020
  • Posts: 7
Reply with quote
Post Posted: Sat Jan 30, 2021 11:14 am
With a screen of padding (total 1792x1504 pixels), the game data uses 10541 bytes for the scroll table, and 1904 bytes for the meta tiles. This has worked out far better than I'd hoped, thank you very much!
  View user's profile Send private message
  • Joined: 08 Sep 2018
  • Posts: 253
Reply with quote
Post Posted: Sat Jan 30, 2021 6:02 pm
responding to psidum

I think for the sake of say small game maps and open RPG like maps, GSL 1.0 does the job. 4 tiles per meta tiles are perfect and allow enough speed and diversity for open area maps that are meant to scroll all directions. When it comes to things like platformers, space shooters, or any ideal side scroller that demand a long horizontal or vertical map space it can be a bit weak.

UGT doesnt let the user change the size of meta tiles and have a scroll map exporter that can adapt to that change... And GSL 1.0 follows with no support for that on the back end either.

Like you said, its all on the formatting.
large meta tiles are amazing for large maps that are long and ongoing (metroid being a good example with its full screen meta blocks, same for micro mages). Small meta tiles work perfect for small or compact maps that need less repetitive details and an open movement space to tell its story.
  View user's profile Send private message
  • Joined: 08 Sep 2018
  • Posts: 253
Reply with quote
Post Posted: Sun Feb 07, 2021 3:45 am
Last edited by IllusionOfMana on Yesterday at 5:23 pm; edited 1 time in total
IllusionOfMana wrote
Note to anyone wanting to use this library.

Its kind of tight on timings. It should be the very first task you execute on VBlank before doing other things such as PSG Updates or I/O port operations.
If you have a "dual threaded" task based system where you exx and ex AF,AF' on the interrupt to give the interrupt its own register set to work with then the following is very important.
This library destroys that paradigm since it requires both register sets to operate during its VBlank routine. Protect thyself! Since it happens during VBlank, you may need a different method of preserving your registers when the unexpected jump occurs.
Some thoughts Ive had about it is pushing important registers on the stack and popping them when you finish your VBlank work. Saving registers to a fixed cache in ram is also an option... but these operations can be kind of slow compared to exx so keep that in mind. Obviously tutorials here suggest just pushing and popping AF which is a quick and safe option. I suggest storing HL as well since it and AF will most likely be the most used during active screen operations.
Lastly, the provided example Demo with the library makes a decent template to follow. It tells you when and where things should be called as well as what is required for them. Stick to that order or GSL will not work well for you at all.


Update on this.

Issue to look out for:
I have had mixed results on vertical or horizontal only scroll able maps that fit the screens height or width. GSL 1.0 doesnt seem to like maps at the size of or smaller than one of the dimensions of the screen. I cant verify if its just a specific issue to me at the moment but wanted to ask the community if they've hit this issue too. I at the very least wanted to warn that this may be something to look out for if you use this library. I have had to bump maps up in size by a few tiles due to draw issues.

Suggested Setup Structure for GSL 1.0.
This isnt actual code, some of the mundane stuff like palette and tile loads are not explained. You can find that in Maxim's tutorial on the development side of SMS POWER.
This is basically one of the best setup structure I have found with GSL. There are very important things you need to keep an eye out when coding for GSL... Mainly not forgetting the HALT at the end of your prog loop.
It works flawlessly on multiple emulators, I havnt tested it on console yet but will update when I can.


Game_Init:
   ;set up vram
   Clear VRAM Routine

   ;load data into vram and ram
   Load Palette Routine
   Load Tiles Routine
   Copy MetaTiles to RAM $C300   ;(You can define your own ram location)
   
   ;set up the scroll table and initialize GSL
   LD HL,Scroll Table Address
   LD BC,MetaTiles RAM/ROM Address
   CALL GSL_InitializeMap
   
   ;set the start position
   LD HL, your desired x position on map in word size
   LD BC, your desired y position on map in word size
   CALL GSL_PositionWindow
   CALL GSL_RefreshScreen

Program_Loop:

   ;===>your program code here <===

   ;call the active display routine to set up buffers for the next frame
   CALL GSL_ActiveDisplayRoutine

   ;YOU MUST CALL THIS HALT AT THE END OF YOUR PROGRAM LOOP
   ;OR GSL WILL NOT OPERATE CORRECTLY
   HALT
   JP Program_Loop

VBlank_Routine:
   ;set up for vblank
   DI
   PUSH AF
   PUSH HL
   
   ;updates the screen buffer in vram
   CALL GSL_VBlankRoutine

   ;===>your vblank program code here <===

   ;prepare to return from vblank
   POP HL
   POP AF
   RETI


EDIT 2:

Notes about scroll issues via user error:

Be mindful about how you handle the scroll increment/decrement routine. Its very much up to the user to keep track of the scroll bounds and if you do not, you may run in to out of bounds draw errors.
I suggest using the scroll functions featured in the GSL 1.0 tutorial/demo script as they clamp the scroll at the edges of the map. This should be implemented for any scroll paradigm where you use GSL 1.0 even if scroll is not directly controlled by the players inputs.
Another thing to keep in mind... You can accidentally overcome the clamps used to keep the screen in the map space by passing a "negative" value through the clamp check and scroll routine when it expects the scroll offset value to be "positive" and vis versa. The result of this will also gain you the dreaded out of bounds draw errors.
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 2859
Reply with quote
Post Posted: Sun Feb 07, 2021 9:24 pm
IllusionOfMana wrote
I have had mixed results on vertical or horizontal only scroll able maps that fit the screens height or width. GSL 1.0 doesnt seem to like maps at the size of or smaller than one of the dimensions of the screen. I cant verify if its just a specific issue to me at the moment but wanted to ask the community if they've hit this issue too.


I talked with Psidum about this once, I remember that he said GSlib wasn't supposed to handle maps that weren't both taller and wider than the screen (I had asked for h-scroll only if I remember correctly).

So yeah, map padding is a possible solution.
  View user's profile Send private message Visit poster's website
  • Joined: 08 Sep 2018
  • Posts: 253
Reply with quote
Post Posted: Yesterday at 5:51 pm
After really working with this for the past 2 and a half months I can say its solid. Once you get past its extremely strict setup requirements, you can do whatever you like with this and PSG-Lib running together.
The fastest scroll speed you can accomplish with this is at a blistering 480 pixels per second(60hz) using an 8 pixels per frame offset value. I cant say that at those speeds it wont cause some slight draw issues on the left or right due to the tight overscan (or even work on real hardware) but I can say you sure can "blast process" on the SMS with this if you learn how to work it and push it.

I hope if there ever is a GSL 1.x or 2.0 that resizable meta tiles becomes a thing because that will absolutely open the door for more creativity on the platform.
  View user's profile Send private message
Reply to topic Goto page Previous  1, 2



Back to the top of this page

Back to SMS Power!