1

Development / Re: Importing images higher than 16-bit.

« on: January 31, 2023, 09:31:50 AM »

Hello,

Technically, you can use the whole 32-bit color palette for your images, and sprites size have no limitation. However, you must be aware that by default, the game uses a 16*16 pixels collision box for the hero and most entities, so if you want hi-res sprites, you'll need to use Lua scripting to change the entities' size as well as their origin point (which also defines their map coordinates). This includes their sprites too, to keep things aligned.
However, doing so is likely to cause collision bugs, so be careful to stay in multiples of 8 pixels for the collision boxes (sprites don't matter).
Tiles can also be of any size as long as they respect the 8-pixels rule (the editor forces you in this direction anyway).

2

Development / Re: Ressource pack zelda ALTTP

« on: September 28, 2021, 10:39:51 AM »

Actually, both worlds are in sorted in across all three tilesets, organized in sections depending on their usage. Feel free to explore them and to learn how it works.

Otherwise, finding and "add[ing files] to the project" or "import[ing] from another poject" isn't that hard, and there are many turorials on how to do this.

So good luck with your project (and feel free to ask if you need help, there will alwys e someone to answer or give you hints).

3

Your projects / Re: Minish Cap Maps in Solarus

« on: August 05, 2021, 11:08:46 PM »

The max number of loadable map elements is purely Lua interpreter limit (confirmed by running the big map through Zerobrane), so unless the team writes a manual map loader from scratch (which is unlikely, as there is not a large demand as the time of writing, bsically there are only you and Adrian, as well as the one who wanted to remake Zelda II, though i can't remember how he manages the map(s?), who make "mega maps" ), or Lua gets more constants memory size in its VM (again, unlikely i fear), you'll have to take that hard limit in account.

That said, in your case, the overworld map of Minish cap is small enough to not be an issue, if i refer to your stats, especially since you will have many tiles larger than just 16*16, which inherently reduces the elts count, so... go! Go! GOOOOOO!

4

Your projects / Re: Minish Cap Maps in Solarus

« on: August 04, 2021, 09:22:15 AM »

Just a quick warning: big maps can not have more than 65534 elements (tiles and entities) on it (+the base properties, that makes 65535) due to Lua interpreting each entry as a constant (someone had the case on Discord and i had to spit the files into two smaller parts for him to be able to open them again). So be careful, make regular backups (and prefer making muliple smaller maps while still possible).

Otherwise, good luck with your repro, can't wait to see the final result!

5

Your projects / Re: Quest Log Menu

« on: January 26, 2021, 09:32:02 AM »

Or maybe we can consider completed full libraries that got in actual finished games as actual projects? 

6

Your projects / Re: Quest Log Menu

« on: January 24, 2021, 10:02:58 AM »

Question: wouldn't it be better to put this in the "Your scripts" section instead ? Because i think this one is for actual games/softwares

Anyway, thanks for your effort in having contributed to the very first commercial project on Solarus

7

Development / Re: Side scrolling functionality

« on: January 18, 2021, 10:14:30 AM »

[Sorry for the necropost but since this thread has been mentioned on the Discord, i wanted to make an update before it goes forgotten under tons of Discord messages]

Some of you may already know but i actually tackled on rewriting the sidecrolller system for a Zelda: Links Awakening remake (ALTTD - A Link to the Dream).
As of today (2021, january 18th), the script is stable enough to be used in another project (in fact, someone did test to do it with success). You can find it here: https://gitlab.com/zeldaforce/zelda-alttd/-/blob/dev/data/scripts/maps/sideview_manager.lua.

This is still in development, though, since the internals are quite a hack, especially the sprite and hero movement  management, so i am in the process of using custom states instead. (it is already written in a separate branch, but it broke the ladder-top detection).
Also, the system works badly when you try to walk down slopes, (unfortunately, i don't have any idea how to handle this, maybe you can help me somehow ?), but this is a low-priority for now since the main project it is used on has none.
 
Prerequisites:
- Since it overwrites some of the metas, you will have to use a script that does allow multiples occurences of the same event (the multi_events.lua, which is required by the script, see header for more information), and never use the direct call to hero:on_position_changed, game:on_map_changed and hero:on_state_changed, since they are the triggers to launch the multiple timers used to update the Y-positions of the affected entities and the movement/commands handling for the hero.
- You will also need scripts/states/sideview_swim.lua, found in the same repository, and the following additional animations for the hero:

Code: [Select]

swimming_scroll
stopped_swimming_scroll
lifting_heavy
swimming_scroll_loading (+sword_loading_swimming_scroll for the sword sprite)
climbing_walking
climbing_stopped
Remarks:
- To make entities jump, just set your_entity.vspeed to a negative value.
- Being a fan project, the remake may be taken down at any point, so if the links get broken, then i will attach the script here instead.

8

Development / Re: Is there a free audio converter to .it impulse tracker for windows

« on: September 10, 2020, 06:09:32 PM »

I think (s)he refers to maps with generic premade structures, which you can copy/paste then resize to your own needs. These maps are sometimes referred to as "store" for obvious reasons.

9

Development / Re: Is there a free audio converter to .it impulse tracker for windows

« on: September 06, 2020, 07:57:39 PM »

FYI: ALTTP uses 1024*1024 regions, which can be divided into 2 to 4 subregions, horizontally, vertically or both.

10

Your scripts / Re: [WIP] Ceiling dropping effect (ALTTP)

« on: September 23, 2019, 01:57:22 PM »

Sorry for the necropost, but since i will be using MetalZelda's version in a project (the Link's Awakining remake) with some adaptations, i wanted to know if you're okay with us using GPLv3 as a license (with full credits, of course) ?

11

Bugs & Feature requests / Re: Lttp tileset not being recognized.

« on: July 21, 2019, 07:24:27 PM »

It may sound dumb, but did you register the tileset to the database using "add to quest" right-click option in the file tree?

12

Development / Re: How to configure game window

« on: July 20, 2019, 09:19:36 AM »

To make sure I am understanding this right, you mean to say the code should look more like this?:

Code: [Select]

map_meta:register_event("on_started", function(camera)
--stuff
end)

In occurence, it will have to be

Code: [Select]

map_meta:register_event("on_started", function(map, destination) --the destination is optional in our case, but this is for completeness regarding the API examples
  --your map initialization code
  end)
Remember that in that case, the first argument for an event callback is always the object that triggered it (here, the new map).

when they wrote

Code: [Select]

self.get_camera()
they should have instead written

Code: [Select]

self:get_camera()
 or
self.get_camera(self)
, right?

Exactly, that's the spirit.

13

Development / Re: How to configure game window

« on: July 19, 2019, 10:43:12 PM »

Actully, what differenciates foo.bar() from foo:bar() is that in the second case, foo is automatically passed as an argument to the bar function, and thus it is equivalent to writing foo.bar(foo)

Anyway, your code is missing an important thing: when you called

Code: [Select]

map_meta:register_event("on_started", function()
--stuff
 end)you forgot to add an argument for the map object which is needed to fetch the camera and which is automtically passed by the event. Speaking of "self", your code will be easier to read and debug if you use an explicitely named variable for the first argument.

14

Development / Re: How to configure game window

« on: July 16, 2019, 09:47:17 PM »

It is perfectly possible to achieve this HUD style, by using the camera API to resize and place it on the screen at game initialization time (generaly in the game:on_started event). For the HUD itself, you will likely want to place it in a menus/hud.lua menu script, and use the menu:on_started and menu:on_draw events to build and update the surfaces which you will display on the screen. See this page for more informations about menus, and don't hesitate to peek a view into the team's games to have an inside of their inner works.

Bonus track: you can display the amount of money(?) as "000" using string.format("%03i", your_variable) when building the text surface for the HUD

15

Your projects / Re: Story Idea: Zelda cross Time Crisis

« on: June 13, 2019, 09:46:45 AM »

Hello,

Yes, you can completely create this kind of game :
- You can use mouse events and sprites to handle the reticle and shoot;
- the cover system can be done by overriding the on_command_pressed and on_command_released events
- Ammo management can be done through an item or a simple variable attached to the hero, your choice
- shooted bullets can be either enemies or custom entities, your choice too

So, all i have to say is: let's go!