Language…
6 users online: Firstnamebutt, Klug, Mario's GameBase, playagmes169, qantuum, Zavok - Guests: 233 - Bots: 339
Users: 64,795 (2,378 active)
Latest user: mathew

Posts by lx5

lx5's Profile → Posts

  • Pages:
  • 1
  • 2
  • 67
  • 68
  • 69
  • 70
  • 71
A standalone .exe version isn't going to happen from me. Releasing Python scripts as executables isn't exactly easy and they're treated as false positives most of the time by antiviruses, not to mention that these .exe files are anormally big for what they actually do.

I'm afraid to say I have no idea what's going on on your side, I've tried the script with Python 3.8.5 and it worked fine.
I'd say you can use [compare=*,*,*,*,*] for that, but compare doesn't wait for anything as far I remember. Shouldn't be that hard to implement if it's tied to button inputs.

As for the second question, I added a tag to change the space width in 2.0, it's [space width=*].
Originally posted by Polaris
This may or may not be intended but the latest versions seems to break compatibility with the SA-1 hybrid patches I used. I don't know if it's just those patches or if the entire section is just borked with this new update.

It'd help to have a list of the patches you have conflicts with. The only thing that may have broke something is the DMA remapping, but that was on v1.35.

Originally posted by SA-1 Pack v1.35 changelog
- Added DMA remap which moves all game DMA logic to channel 2 and Windowing HDMA to channel 1, freeing up channel 7 for custom HDMA. In addition, DMA channel 0 is now reserved for transfers during game play (outside interrupts), fixing a rare bug on the LZ2/LZ3 decompressor when you decompress a GFX file while the game is running and *just* when the DMA executes, a NMI occurs and the DMA settings end up reseted. For the effectiveness of this solution, please change all patches to use DMA channel 2 instead of 0 or 1.
you liar







i'll try to play it at some point
Hi there traveller! I'm coming this C3 to show stuff I've done.



Dynamic Spriteset System
GitHub repo
DETAILS HERE

As the title I want to evade the thought behind building spritesets for levels in SMW, that's why I've created a system that completely builds them during mid level, that's right, once the sprite is loaded into memory it's graphics will be uploaded to VRAM in small chunks.

This will be uploaded to GitHub in the future alongside with some documentation about how to convert sprites (spoiler: requires asm knowledge!) and some "limitations" this has.

I'd explain in detail the inner workings, but i'm kinda burned atm, I'll cover that in a future post :P

BUT I prepared a small video showcasing this system and you can watch it right here:



small edit: Also I'm aware Yoshifanatic, anonimzwx and katrina have made very similar things to this, so I'm not the first one on doing this :)



Modernized Romi's VWF Cutscene tool
GitHub repo

I decided to fix this tool some months ago, I also made a post about it before but I want to include it here regardless of that :P

You can read a detailed readme, changes, etc. in this other thread







Asar Syntax Highlighter for Visual Studio Code
GitHub repo

I finally made the switch to another text processor that wasn't the old and reliable Windows Notepad, but I also wanted to take advantage of VSCode's syntax highlighter so everything isn't painted blue. I decided to build a syntax highlighter and this was the result (you can open the image in another tab for the actual size):




That's all I can show for now. See ya later!
Thanks everyone for the nice reception!

Long post incoming!!



Dynamic Spriteset System details

The Dynamic Spriteset System (DSS) is a compilation of several ASM hacks and edits to existing sprites to allow dynamically filling the VRAM at SP3/SP4 regions via requests of sprites loaded in memory. This means that any non visible sprite on the screen will not have their graphics on SP3/SP4 and you won't have to waste time messing with disassemblies, hex edits or small patches to manage your spriteset for each level you want to make.

The system is separated in three different and smaller systems: the request/queue GFX routine, the VRAM queue system, the new sprite detector and the garbage collector. This system relies on ExGFX files which are inserted via Lunar Magic.

Request/Queue GFX routine
This routine has two primary functions which depends on wheter the sprite has been its needed graphics on VRAM and accesible at the current frame (more on this later).

The first function is the one that puts the necessary tiles which are not present nor accessible in a queue to upload them to VRAM at the start of the next frame/NMI interrupt. This function also covers other aspects of the whole system:
  • Decompress ExGFX file (which can be up to 3KiB)
  • Mark tiles in SP3/SP4 as used so any other sprite which requests their graphics to be uploaded to VRAM don't overwrite these used slots
  • Save the tiles used to two buffers: a temporal one which will be overwritten the next time the routine is called and a persistent one that holds the same data as the temporal one as long the sprite remains in memory/in screen and can be requested at any time. The persistent buffer is actually a big buffer that holds the information for up to 32 different ExGFX's tile number data, basically an array of arrays.

The second function is far less complex but still very important, it requests the tile data from the persistent buffer which is copied into the temporal buffer for easy access in the sprite code. The routine won't provide any data if the tiles haven't been uploaded to VRAM.

There are moments in the video where you can see a lot of duplicated graphics which ends up looking really bad. This was due to them being marked as "not accessible" or "unused" since no sprite or any other code tried to use these graphics in the previous frames, thus making necessary to put the tiles into the VRAM queue again.
The graphics will be marked as "unused" once a certain amount of frames have passed since the last time their tile data was requested. The default duration is 16 frames, I'm still experimenting with this so it may change later (presumably to a little higher value).

VRAM queue system
A queue system to upload graphics to VRAM was pretty much needed to upload the needed graphics in small chunks every frame to avoid any kind of flickering/overflow.

I designed the system to be a ring/circular buffer with 64 possible entries while each entry holds 4 bytes worth of data. The data stored is a VRAM destination (2 bytes) and the RAM buffer location (2 bytes, bank byte hardcoded to $41). It being a ring buffer helps to avoid making complex calculations when it comes to update the index used in the routine.

Every frame it will try to upload a fixed amount of 16x16 tiles (7 at this moment) in the quickest way I could come up with. I haven't measured the routine in regards of its cycle usage yet, so the amount of tiles uploaded each frame may be reduced depending on how demanding this is.

The system may be used to upload different things to other VRAM regions, but I haven't done anything with that :P

New sprite detector
Kinda misleading title, but it isn't a new version of some sprite detector, it detects sprites which where spawned in the current frame.
It sounds like a kinda unnecessary thing, but it was needed to avoid an extra frame of delay for sprie graphics to appear in some cases where sprites were spawned in the same frame and their slot wasn't executed, thus not putting their graphics into the VRAM queue (if needed). It also helps to upload graphics for extended and cluster sprites. And finally, it helps to avoid hijacking every single spawn routine in the whole game.

This routine it's just a bunch of loops and it's quite slow... but if it helps me to not hijack a lot of places (more than I actually have lol), then it's a good trade.

Garbage collector
The garbage collector is the routine in charge of marking tiles as unused every frame. It doesn't do much, but it's still quite important part of the whole system.

It was already explained, but again with a little extra details: to get sprite graphics to be marked as unused, the ExGFX file should not be called for a fixed amount of frames. Once a sprite GFX is marked as unused, everything about them will be marked as unused, this includes their data in the persistent buffer, making the tiles in VRAM not accesible, even if they're present.

You can simply avoid getting graphics marked as unused if you request their data from the persistent buffer using the included routine (or just reset their timer), this isn't limited to sprites, you can also do this via UberASM or custom blocks!

Random bits
  • I decided to use Lunar Magic's ExGFX system since it was quite manageable to decompress graphics via SA-1
  • It took me about a third of a year to design the whole thing, I have a hard time coming up with ideas
  • I did make something similar and showcased it some time ago, the main diference is that the spriteset was built at level load and NOT during actual gameplay, which didn't allow for a varied cast of enemies in a level
  • The current system doesn't play very well with reskins of sprites, I haven't come up with a good method to allow them
  • Adding more ExGFX files is actually quite tedious, as you have to edit at least 2 different files: you need make a define which points to the ExGFX and you have to edit a table with the amount of 16x16 tiles your ExGFX has.
  • It will require a fair amount of ASM knowledge to get this to work with custom resources. The system is fairly simple to use, but you have to know which parts of the GFX routine you have to edit and I'm sure I can't assist everyone to examine every single one of their sprites.
  • Every single original sprite will be modified to use this system, it's a long and tedious work, but it will be worth.
  • I will try including .ssc, .s16, .mwt files to fix the look of sprites and have them show fine in Lunar Magic regardless of the loaded graphics in the level.



Originally posted by Ninja Boy
Even if this system doesn't extend to custom sprites if you can say use 2 of the 4 files for the dynamic system and 2 for non-dynamic stuff that opens so many possibilities for sprite combos.

This is quite possible! You can limit how many sprite tiles will be used for the dynamic spriteset system via uberasm, as there is a RAM address that controls exactly that. It will be removing the posibility to use sprites from the bottom of SP4 to the top of SP3. This is particularly useful for dynamic sprites made for DSX.

Originally posted by TheLegendaryOrb
What can the Dynamic Spriteset System do? Am I understanding it correctly that it can change the SP1-4 dynamically?

Just SP3 and SP4; SP1 and SP2 will remain the same, SP2 will now have a lot of blank areas due to every enemy from there is now part of the dynamic spriteset system.

Originally posted by qantuum
I expect the syntax of the message writing to be easier, but I'll find out in the github repo :D

It's pretty much the same as the original version, it just doesn't require ActivePerl :P
The main feature of my update is that it now includes a ton of new commands to play with.

Originally posted by Final Theory
I really like the Modernized Romi's VWF Cutscene tool. Can you load custom sprites in it instead of just vanilla sprites?

The VWF cutscene system (both old and modern) allow for any sprite graphic in SP1, SP2, SP3 and SP4 to be displayed in screen at any position. You can load any ExGFX in these slots via Lunar Magic and you can use them just fine! In fact, that's how SMWCP1 did their fancy cutscenes

Originally posted by Final Theory
Also how do you trigger these cut scenes. Is it after you beat a particular level?

You place vwf.json and vwf_data.json (this name may vary) in the level and a cutscene will play.

Originally posted by Final Theory
This is an excellent way to tell an actual story and such. It would be great if there was a way to make sprites and such act out stuff like in FF3 or Chrono Trigger.

It may be possible, but it will certainly require ASM knowledge! (You can hijack your own ASM into the cutscenes).

Originally posted by Final Theory
Can you talk to an NPC in a level and also trigger this dialogue?

If you teleport to another level, yes.

Originally posted by imamelia
I know I asked before, but have you tested the spriteset system both with and without SA-1? Is there an option for the latter, at least, to have the graphics uncompressed to save processing time??

I really don't have plans to make a non SA-1 version as I want to stick with the ExGFX approach I have. However, as I've mentioned in discord, this function it's pretty much isolated and you can modify it to use pointers to ROM instead of ExGFX files; the easiest way would copying the GFX data to a RAM buffer so you don't have to modify the inner workings of the VRAM queue system, very similar to how DSX works.
That said, the code already includes the necessary stuff to make a non SA-1 version, I'm way too used to append |!dp and |!addr to anything I program.

Originally posted by Atari2.0
as for the VWF tool, I can't say I'm surprised because I helped you revamp it quite a bit, sooooo I'm gonna comment on the last thing, the syntax highlighter is amazing, I've been using it since you made it and honestly it improved my asm experience by a lot, it's so nice being able to distinguish things by color and not have to look at a wall of black and white text.
Here's to more projects!

You were VERY helpful in the VWF tool modernizations! I'm glad you wanted to revamp the code without me asking lmao.
I'm super glad people have found my highlighter useful! It was a good excuse to learn regex haha.

Originally posted by RPG Hacker
Pretty great seeing another syntax highlighter for Asar. Admittedly, some things are highlighted in a way that seems a bit weird to me, but I'm guessing it was probably easier to do that way, and in any case, having different highlighting options is always good.

I have weird color preferences haha. Everything is super customizable though. Almost every part has its own scope which can be colored or stylized in a different way.
There was an exising highlighter in the Extensions Marketplace, but it was quite bad and didn't support asar's functions which annoyed me a bit. Basically:

(restricted)
Originally posted by MarioriaM
Will the the Dynamic Spriteset System work with your custom powerups patch? Wonderful work your doing here.

Not likely, as I don't want two big patches relying on each other. Plus this one still doesn't have proper non SA-1 ROMs support while the powerups do (and probably won't receive said support).
Neat!

I'm glad i was able to help you out testing a little bit this update, which was one of my most wanted updates since 2019 when you made an article in SnesLab.

I'm looking forward to use it in my projects :P
Originally posted by JupiHornet
That said, how easy would it be for new hackers to implement it? I ask because the thread says it requires ASM knowledge.

I'm afraid it will not be easy to convert custom resources to use it. It's not just adding a few lines of code, you have to know where you should put them in order to be effective. And as I've mentioned, this is aiming to be compatible with every SMW original sprite on a SA-1 enhanced ROM.
Github repo

The project is now on GitHub. I wrote some quick stuff about how to use it, but it still is pretty early for regular users to actually make a hack with it.

The core part of the system is done and it's just matter of converting the original sprites to be compatible with this system.

Anyone is free to contribute to convert any of these. Feel free to contact me in #lx5-laboratory in sneslab (link on my title) if you have any questions regarding the (very little) docs I've included. I don't accept DMs btw, I don't like them.

I have nothing else to show, so that's really everything I had to offer. I hope you all liked it!



lol ninja'd

Originally posted by 1UPdudes
Is there any real hard limit to what and how many sprites can be in one level now or are all sprites able to be in one level?

As long you don't have over 64 16x16 sprite tiles loaded (maximum limit, which also is configurable) in the same area, anything will be possible to be loaded in the level.
GitHub repo
Latest version (v1.01)




The Dynamic Spriteset System (DSS) is a compilation of several ASM hacks and edits to existing sprites to allow dynamically filling the VRAM at SP3/SP4 regions via requests of sprites loaded in memory. This means that any non visible sprite on the screen will not have their graphics on SP3/SP4 and you won't have to waste time messing with disassemblies, hex edits or small patches to manage your spriteset for each level you want to make.

The system is separated in four different and smaller systems: the request/queue GFX routine, the VRAM queue system, the new sprite detector and the garbage collector. This system relies on ExGFX files which are inserted via Lunar Magic.





Features
  • Easy to use API, just call a routine to do the heavy work for you
  • Lunar Magic's ExGFX system to store sprite graphics
  • Lunar Magic's sprites showing fine regardless of the loaded ExGFX
  • VRAM queue system; used to fill the VRAM at the sprite area, but it may be used for something else
  • Yoshi can exist in any environment, it can also coexist alongside Podoboos
  • Glass, ON/OFF and note blocks are now global



Drawbacks
Before you actually use DSS you have to keep in mind a few negative things that come with this:

  • You can't use different skins of sprites without using a disassembly. This means you can't have themed enemies or anything like that.
  • The system puts some pressure on the V-Blank period, it requires this to upload graphics to VRAM as soon as possible in small batches. This will limit how many ExAnimations and other related stuff you can have without seeing a flickering black bar at the top of the screen.
  • Loading compressed graphics can generate a 1 frame lag in case of really CPU heavy situations. You have to put some thought behind your sprite placements if you ever encounter such lag spikes.



Disclaimer
This project was started to completely remove the time spent building manually a spriteset for my very own purposes and took decisions that fulfilled my requirements. If you find anything that isn't ideal for your very own project I'm sorry about that, but it's not likely that any changes will be made for your specific purposes.

I will not provide any kind of support about this system. It's a very complex package that modifies a lot of parts of the ROM and providing support in such cases is outright impossible.

Any question I receive will most likely replied with a link to the wiki unless it's a bug report about the API or any SMW sprite I've converted.



Demonstration
The issues addressed in the previous posts may be fixed in a future version.



Something somewhat important for future releases:

I've been thinking of completely removing LoROM support (aka non SA-1 enhanced ROMs) for a while.

The patch has two major limitations when it comes to sprites:
  • Frame rules applied in some cases where slowdown could have been an issue
  • Sprite tile limitations ended up forcing an actual limit of certain sprites generated via powerups (bubbles, ice blocks)

SA-1 Pack v1.40 was released not too long ago and it comes with really nice OAM features that would come handy for a project of this magnitude (MaxTile, OAM priority, less prone to slowdown).

Another thing that has been on my mind lately is that with the release of Dynamic Spriteset System (DSS), it would be possible to remove some DMA features that were added due to really limited space in SP1/2 for powerup graphics, namely the dynamic projectiles and dynamic powerup items.

While I really don't like forcing the usage of big patches (SA-1 Pack & DSS), it will greatly help for the future of the project, even if I'm not working on it that much anymore. This decision will be made once DSS is finished and confirmed to work flawlessly on the original game.
this isn't dead btw

progress is being made and the conversion/evaluation of every sprite ID in the game (0x00-0xFF) is about 70% done. hopefully in this month the list will be completed. you can track the progress in either in my channel at sneslab or this github issue

there isn't much left and proper testing will begin, as i need to evaluate the flow of a level where things aren't as regulated as my test suite (only test one or two sprites at a time) so i can adjust some smaller things in this system such as the amount of tiles uploaded to vram each frame or the amount of available decompression buffers for graphics





every single sprite has been evaluated and converted if necessary for DSS.

all that's left is testing stability and finishing the wiki

and speaking of the wiki, it's mostly complete at this point, you can read the progress here: link

and finally... i've added a disclaimer about my stance on this project on the repo, which i'll post here as well:

Originally posted by me on github
This project was started to completely remove the time spent building manually a spriteset for my very own purposes and took decisions that fulfilled my requirements. If you find anything that isn't ideal for your very own project I'm sorry about that, but it's not likely that any changes will be made for your specific purposes.

I will not provide any kind of support about this system. It's a very complex package that modifies a lot of parts of the ROM and providing support in such cases is outright impossible.

Any question I receive will most likely replied with a link to the wiki unless it's a bug report about the API or any SMW sprite I've converted.


a little bit controversial, but i do hope you guys understand my goal with the project.
Originally posted by Thomas
This is super impressive, and something that seems like it'll be incredibly powerful in use. Hopefully we'll see more widespread support for it over time, at least as alternative versions to sprites.

Yup! This will be extremely useful in a lot of situations and it's a little bit customizable as well via uberasm :P

It's possible to test DSS right now, but I haven't finished deciding how everything will be organized nor I've finished the custom displays for sprites in LM so they don't show as garbage in the editor so things are going to be updated and may not be exactly the same in the final release.

Once I'm done writing the wiki and finish the things I mentioned above I'll publicily ask for testing. I really want this to be stable and feel natural when it comes to designing levels and have clear enough instructions.
  • Pages:
  • 1
  • 2
  • 67
  • 68
  • 69
  • 70
  • 71