new Node tileDraw

[jonSP12]

Describe the project you are working on

This is a tileSet editor Ive made for the godot editor

----///---newer version -----//-------
https://youtu.be/kgiRmHoHIX4?si=dRrOpSpIefaa6GVu

----///---old-version-video-----//-------

2024-08-29.11-22-27.mp4

the benefits are big ( PROS ).

• draw with tiles like in a photoshop drawing program
• change tile color
• add filters like blur, pixelatte, Hue/Saturation..etc..
• merge all layers into one layer
• all basics are here, draw with left Mbutton / erase right Mbutton
• select/copy tiles from editor viewport

the CONS

• it creates a new texture for each tile
• The user will have to decide the best approach... Merge all layers into one to reduce the nº of textures
• The user will have to decide, the canvas size ( image size )
• Its mostly used to draw levels like in "HOLLOW KNIGHT". Not destructive levels like "BRO FORCE"

Describe the problem or limitation you are having in your project

• unability to change a tile(s) color
• unability to blur the background layers in 2D ( giving a deph of field effect )
• colors not matching using a normal tileMap
• extra effects like blur/pixelatte take a lot of work and RAM resources in a normal tileMap
• In a normal tileMap only the entire color can be changed, not a tile or group of tiles

Describe the feature / enhancement and how it helps to overcome the problem or limitation

This tileDraw editor, would benefit users that are making more advanced 2D games ( HOLLOW KNIGHT TYPE ).
currently a user has to change between photoshop / tiled and then engine editor, to make a level of this sort.

This node would give the user the oportunity, to make / draw the level and edit it in just on place, making the level look better, and easier to edit.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

dificult to describe in only a few words
This is a very old example of the code on gitHub
https://github.com/jonSP12/tileDraw_plugIN_test3

The code needs to be remade, but this is not a problem, i can do it very fast with my eyes closed.
The reason i havent yet remade the code is:

• The undo / redo feature is not working 100%, has this feature is part of the engine.

If this enhancement will not be used often, can it be worked around with a few lines of script?

na

Is there a reason why this should be core and not an add-on in the asset library?

It can be added has a plugIN, but making it core is not very hard the code is very basic, and easy to change based on changes made to the redot editor. Seeing this changes on the editor its the kind of things Users want.
This would put redot on the right track and going foward, since tiles in godot always seem to fail, or lead to Bans. Redot can start from the top, instead of starting from the same tileMaps clucky 3.x to 4.x negleted process that godot comes up with.

The main reason and my personal experiece, is that tileSets were always some sort of TABU in godot. Starting in 3.x, later in 4.x. Mentioning this topic is like steping into a nest of vipers...

You can see in this post in 3.x godotengine/godot#61187 i mentioned the tiles in tileAtlas were all scrambeled like a jigSaw puzzle... At the time i didnt knew how godot worked so i didnt knew how to fix the problem myself. The issue seemed to negleted by the person in charge of making tiles, then easly fixed by a user ( kleonc )

Having the tiles showen like in the image is just a very basic thing. Funny enough they only seemed to pay attention to the subject after 3 years when i was banned... This is the main problem i have with the godot engine, and why i think opening issue or even mentioning improvement is just a waste of time... the devs there dont know how to do it.
This results in excuses that dont make sense, and myself and others being tagged has "rude" or other weird labels.... A very easy insight is that we are making this things and not asking users money for this !!!
( why are the people making bad editors apps not BANNED ), its a discustion that leads to nonSense.

[Spartan322]

I don't see what the point of this proposal is, Godot already has a tileset system thats competent, if you need more it probably should remain a plugin.

[jonSP12]

if you need more it probably should remain a plugin.

The undo/redo isnt working 100% with the engine undo/redo, the only way i can get it working is to code a new redo/undo.

I don't see what the point of this proposal is, Godot already has a tileset system thats competent

open any tileMap in godot 4, and apply these filters or change color to each tile or group of tile(s) there. ( tiles in the same layer )

[jonSP12]

[edit] you ve opened redot and said you would wanted to add new features to make "" game Dev easier "" ....

This is has best has it gets, change tile color / add filters...
People were holding on using godot 3.x because of its tiles, tiles in godot 4.x are good, but can be better.

Anyhow new feature easier to draw levels, any person using tiles can see changing the tile color is a great improvement... Its either that or use a drawing program instead of a tileSet.

[Spartan322]

The undo/redo isnt working 100% with the engine undo/redo, the only way i can get it working is to code a new redo/undo.

Then the current system should be fixed.

open any tileMap in godot 4, and apply these filters or change color to each tile or group of tile(s) there. ( tiles in the same layer )

Its rarely worth it to add features just to add them, it create complexity the introduces bugs and maintenance burden, it needs a usecase that justifies the maintenance even aside from community consideration, I have yet to notice any mass desire for such a feature.

you ve opened redot and said you would wanted to add new features to make "" game Dev easier "" ....

Not especially no, Redot seeks to measure community interest, and that interest needs usecases to justify the burden of development and maintenance. If that case can't be clearly and widely demonstrated, the whole point of the engine otherwise is to allow you to maintain such things for your needs without putting even more burden on the Redot team, Redot is not made to provide for your every usecase, no game engine is, we can't handle integrating every feature somebody wants, it needs to be measured by community interest and it shouldn't overtake a preexisting system, if you have an issue with a preexisting system, it should be fixed up, not replaced.

Anyhow new feature easier to draw levels, any person using tiles can see changing the tile color is a great improvement... Its either that or use a drawing program instead of a tileSet.

But at a certain point its better to use better designed and maintained tools anyway and bring them into Redot, Redot isn't intended to be an all encompassing tool, but a satiable tool for most people foremost, and if someone needs a more advanced tool, either use a dedicated solution which will do better then the engine could ever possibly do or implement your own dedicated solution. (unless a mass clamoring for the tool upgrade is made)

[jonSP12]

But at a certain point its better to use better designed and maintained tools anyway and bring them into Redot, Redot isn't intended to be an all encompassing tool

I dont know of any tool that can do this... Photoshop doesnt allow to draw with tiles... Tiled doesnt allow to change the tile color or effect.

Its rarely worth it to add features just to add them, it create complexity the introduces bugs and maintenance burden

I think that in this case the burdens would be minimal. The blunt part of the plugIN are the menus and options, these are things made using the engine existing nodes... That is the reason why i though adding this node would be minimal but i could be wrong.

it needs to be measured by community interest.

I have yet to notice any mass desire for such a feature.

Ive always read requests to add an option to change the tile color, in godot and other places. Requests like this will keep poping up now and then. A google search in any tileSet editor will show some kid(s) requesting to change the tile color... I think most people have just gave up on asking for these options, or they are too afraid to ask you, because someone else always tells them its impossible.... + Plus if you would saw a request feature to change the tile color you would problably tell them to use alternative tiles, witch is a very destructive way of doing this type of things, and would cause fear in someone using it, making them move towards other ways to do it instead.

Then the current system should be fixed.

Then plugIN is fine by me, i just wanted to get it running with the engine undo/redo, so it would look better... instead of having 2 undo/redos working at the same time. I was hoping someone who already knew the engine source code could provide a solution for this i believe it could be done in 10/15min, but for me its going to take me about 1 month or weeks to get it working the right way... if ever...

[Spartan322]

I think that in this case the burdens would be minimal.

It inherently isn't, adding a feature requires maintenance, that is a burden, either we must know what it does and manage it ourselves or we have someone on our team who does, neither of which will happen with that feature as it stands right now regardless, we do not have the manpower to do so.

Ive always read requests to add an option to change the tile color, in godot and other places.

I've read the godot proposals issue tracker daily for a while and I've never seen it, in "other places" is irrelevant, we can't support a feature on pure theory.

A google search in any tileSet editor will show some kid(s) requesting to change the tile color

Okay, that's still not a Redot problem.

I think most people have just gave up on asking for these options, or they are too afraid to ask because someone else always tells them its impossible

Then they either don't need the feature or they don't care enough about the feature, its a lot more likely most people don't actually care, I've not seen this case widely desired and merely saying there are some people that may desire it is not good enough justification. If people need something why do people ask for all these other features that are harder to define and why do they get all this support but the same is not said of what you're referring to.

you would problably tell them to use alternative tiles, witch is a very destructive way of doing this type of things

No its not, that's by definition non-destructive, like out of everything doing that would be destructive is most certainly not true.

I was hoping someone who already knew the engine source code could provide a solution for this

Being a fork the expectation is that contributions for some features would also need to be done on the desires of the community's work too, and if it were just 15 minutes of work by someone who knows the engine, it would've already been done in Godot, not that I have an exact idea of even what you want with that.

[jonSP12]

Just to simplify - Adding a feature to change the tile color in gd4.x tileSet would be a bad idea...
The current feature there "alterate tiles" doesnt cover this... Just to change the tile color from yellow to orange, can lead to a lot of problems there are 255 variations of yellow, 255 variations of orange... You could end up with billions of alternate tiles.

I had to frase "new Node" in the title request " new Node tileDraw #33 "
adding a feature to change the color in the current gd4 tileSet would destroy it...

keeping things seperate with a new node, would be easly done. Of course "changeColor" would defer from a normal tileSet, and would look more like a drawing program... This allows to do more things to the image like: filters / blur / pixelatte etc...

To simplify...

• this is the part were i get in trouble, it works the same way has in photoshop
• select the layers / merge the layers / remove the selected layers except for the one the user selected frist...

the layers are in an itemList ( a thing that's in the engine and i dont know how is coded )

#----//--REMOVE-itemList-layer-//----
func _on_btn_del_layer_pressed():
	var listSize = itemList.get_item_count();
	var itemListSelectedItems: Array = itemList.get_selected_items();
	
	if ( listSize <= 1 ):
		return;
	
	
	if ( itemListSelectedItems.size() <= 1 ):
		for n in range(listSize, -1, -1 ):
			if ( itemListSelectedItems.has(n) ):
				itemList.remove_item(n);
				PlugTileDrawNode2.layerMax = listSize-1;
				PlugTileDrawNode2.layers.Lnum.remove_at(n);
				PlugTileDrawNode2.layerName.remove_at(n);
				
				itemList.select(0, true);
				_on_item_list_multi_selected(0, true);
	elif ( itemListSelectedItems.size() > 1 ):
		for n in range(listSize, -1, -1 ):
			if ( itemListSelectedItems.has(n) ):
				if ( n != itemListSelectedItems.min() ):
					itemList.remove_item(n);
					PlugTileDrawNode2.layerMax = listSize-1;
					PlugTileDrawNode2.layers.Lnum.remove_at(n);
					PlugTileDrawNode2.layerName.remove_at(n);
		
		_on_item_list_multi_selected(itemListSelectedItems.min(), true);
	


#----//--MERGE-layers----//----
func _on_btn_mer_layer_pressed():
	#var lays = itemList.get_selected_items();
	var lays: Array = itemList.get_selected_items();
	var listSize = itemList.get_item_count();
	
	
	if ( lays.size() <= 1 ):
		print( "tileDraw: only 1 layer selected" );
		return;
	
	arrMax_x.clear();
	arrMax_y.clear();
	
	for a1 in range(0, lays.size() ):
		var idx2 = lays[a1];
		var imgPos10 =  PlugTileDrawNode2.layers.Lnum[idx2].keys();
		
		for a2 in imgPos10.size():
			var imgPos15 = imgPos10[a2];
			arrMax_x.append(imgPos15.x);
			arrMax_y.append(imgPos15.y);
	
	var arrMax1_x = arrMax_x.max();
	var arrMax1_y = arrMax_y.max();
	var arrMin1_x = arrMax_x.min();
	var arrMin1_y = arrMax_y.min();
	
	var arrMax1_x2 = abs( arrMin1_x - arrMax1_x ) + 32;
	var arrMax1_y2 = abs( arrMin1_y - arrMax1_y ) + 32;
	
	var format = PlugTileDrawNode2.drawText.get_image().get_format();
	var imgSelect1 = Image.create(arrMax1_x2, arrMax1_y2, false, format);
	
	for i in range(0, lays.size() ):
		var idx = lays[i]
		var imgPos = PlugTileDrawNode2.layers.Lnum[idx].keys();
		var img11 =  PlugTileDrawNode2.layers.Lnum[idx].values();
		
		for p in img11.size() :
			var imgPos2 = imgPos[p];
			var img12 =  img11[p];
			imgSelect1.blend_rect(img12.get_image(), Rect2(Vector2(0, 0), Vector2(32, 32) ), imgPos2 - Vector2(arrMin1_x, arrMin1_y) );
	
	var combined_texture = ImageTexture.create_from_image(imgSelect1);
	
	#---breaking-the-image-into-pieces-and-drawing-it-on-screen----
	PlugTileDrawNode2.mouseGroup.Fnum.clear();
	for i in range(0, combined_texture.get_image().get_size().x,32 ):
		for j in range(0,  combined_texture.get_image().get_size().y, 32):
			PlugTileDrawNode2.mouseGroup.Fnum.append(  { "cords": Vector2(i, j), "img": ImageTexture.create_from_image(combined_texture.get_image().get_region( Rect2( i, j, 32, 32) ) ) } );
	
	for i in range (0, PlugTileDrawNode2.mouseGroup.Fnum.size() ):
		var coords = Vector2( arrMin1_x, arrMin1_y ) + PlugTileDrawNode2.mouseGroup.Fnum[i].cords;
		var imgText  = PlugTileDrawNode2.mouseGroup.Fnum[i].img;
		PlugTileDrawNode2.layers.Lnum[ lays.min() ][ coords ] = imgText;
	
	
	print("TileDraw: layers selected: " + str (lays) )
	print("TileDraw: Layers mergeded into: " + str( itemList.get_item_text( lays.min() ) ) )
	mergeRemove = true;
	_on_btn_del_layer_pressed();

this is were i stopped because the undo/redo gets confusing to me...

• This is the undo/redo working has normal on a mouse press/release

	#------------------//-DRAWING--//---------------------
	#------------------//-DRAWING--//---------------------
	
	if ( Input.is_mouse_button_pressed(MOUSE_BUTTON_LEFT) && mouseJustPress == false ):
		mouseJustPress = true;
		
		if ( drawText == null ):
			return;
		
		mouseGroup.Fnum.clear();
		#-----------------------------------------------------------
		#-----------------undo-rendo-draw-------------------------------
		undoredo.create_action("tileDraw - drawing Tiles");
		undoredo.add_undo_method(self, "remove_element", layers.Lnum[ layerPOS ].duplicate(true) );
		undoredo.add_do_method(self, "add_element", layers.Lnum[ layerPOS ].duplicate(true) );
		undoredo.commit_action();
		#-----------------------------------------------------------

--------------//-------//--------------------

	#----------------------//-ERASER--//---------------------
	#----------------------//-ERASER--//---------------------
	
	if ( Input.is_mouse_button_pressed(MOUSE_BUTTON_RIGHT) && eraseCheck == false ):
		eraseCheck = true;
		
		if ( drawText == null ):
			return;
		
		#-----------------------------------------------------------
		#-----------------undo-rendo-erase-------------------------------
		undoredo.create_action("tileDraw - erasing Tiles");
		undoredo.add_undo_method(self, "remove_element", layers.Lnum[ layerPOS ].duplicate(true) );
		undoredo.add_do_method(self, "add_element", layers.Lnum[ layerPOS ].duplicate(true) );
		undoredo.commit_action();
		#-----------------------------------------------------------
		mouseGroup.Fnum.clear();

Dont try to understand the blocks of code above... But the undo works with a very simple function like this:

#---------//--UNDO-RENDO--//--------------

func add_element( value ):
	layers.Lnum[ layerPOS ] = value;
	notify_property_list_changed()

func remove_element( value ):
	layers.Lnum[ layerPOS ] = value;
	notify_property_list_changed()

But for me to add this to the merge layers section ( the part were is not working 100% )
Its too painfull because i dont know whats happening on the other side...
There are more complicated menus in godot/redot like the current tileSet layer menu that use's the undo/redo... and even the tileSet in gd3.x that also seems to use an itemList to store its tiles is using undo/redo just fine...

Just to put it simple an engine DEVs knows how to do it, but i dont... That is why i said it would problably take a dev about 10 to 15min to put the undo/redo in there, because this things have been made in the engine multiple times, and in much more dificult situations...

[edit] my idea about this was grab whatever ( Thing ) an itemList is... And put it inside the undo/redo, and never mind the code... if the user presses CTRL + Z just revert the entire itemList to the previous itemList stored there... somewere in the redo/undo system...