Touchscreen in Mindustry
Вставка
- Опубліковано 10 чер 2024
- The logic for this touchscreen was compiled by a logic compiler. Check out the below Github for more information.
github.com/BnDLett/mlog_compiler
Link to the source code for the schematic: github.com/BnDLett/mlog_compi...
The only image in the thumbnail that is owned by me is the screenshot. Every other image goes to their respective owners. Yes, even the black background. - Ігри
Mindustry into mindustry
very cool, nice touchscreen, I think it can be used for other stuff too!
Absolutely. This was primarily just a test implementation. I intend to possibly use it for something more other than just moving a block around the screen. Then again, as shown in the video, processors as-is are just not fast enough to handle all of the operations that are used. I wrote the system to be highly dynamic, which results in it also being severely limited by logic processor speed. It will also get *a lot* slower with more button implementations.
@@bndlett8752 multi threads?
@@ArdLight I probably could do that but I'm not sure how much it'll help. AfaIk, there isn't really much that multiple processors could optimize.
@@bndlett8752now make a working phone with internet to download mindustry on this phone
How the heck do you do these💀
Use sensor to detect arc firing position it will still be detected even though it have no energy
You can read the turret's target position and whether or not it's firing
Cool, imagine using your units with this💀
I was thinking about that implementation, but I never got around to doing it. It seemed a lot simpler to just make a basic moving block implementation in order to ensure that it worked. Although, if I wanted to, I could absolutely do a unit implementation now. It's just that there wouldn't be much of a use.
@@bndlett8752 ok, it could be used to siege at distance
@@Mantyros No. Mindustry already has a better native implementation.
@@bndlett8752 ok
Why the duck u even need an arc to shoot in it
No specific reason. That's just my preference. Although, it does come with its pros:
1. Only one person can control the touchscreen at a time
2. An arc doesn't need to shoot in order for it's x and y values to be recorded, which is overall more convenient for the user.
Although, it isn't without it's cons:
1. Someone can just force you out of the arc via deleting it, which will basically remove your authority of the screen until you get back into the arc.
2. You need to actually get into the arc first. This isn't as much of an issue on Erekir sandbox maps, but it does cause issues on Serpulo sandbox maps. Especially whenever the schematic is placed a decent distance away from the core.
Alr now let’s try make Minecraft in mindustry 💀
Imagine running doom in mindustry
It's possible, yeah.
Doom in mindystry...
Soon...
It is possible, it's just that someone is going to have to design and optimize a 3D engine.
very cool
U are genius guy😂
Ух если сенсорные экраны есть то можно там запустить дум!
How? Как?
In Russian / русском языках
Читать описание. В нем содержится ссылка как на исходный код, так и на компилятор, который использовался для его реализации.
Хотя в фактическом объяснении:
Сначала он определяет положение дуги и дисплея, вычисляет относительное положение, а затем умножает относительное положение на количество пикселей в блоке. После этого вы получите положение курсора.
Затем он занимает указанное положение курсора и сверяет его со списком значений положения и размера. Эти значения положения и размера предназначены для кнопок. Если курсор находится в нужном диапазоне значений, то он проверит, нажимает ли игрок. Если игрок нажимает, то он, наконец, возвращает значение true.
После того, как оно вернет значение true, будет запущена функция, которая управляет положением блока в зависимости от того, какой блок был возвращен.
Это довольно общее объяснение, и оно не объясняет всей динамики кода, поэтому я предложил посмотреть исходный код на Github, поскольку он показывает полную динамику кода.
In English / на английском языке
Read the description. It provides a link to both the source code and the compiler that was used to implement it.
Although, in an actual explanation:
First, it takes the position of the arc and display, calculates the relative position, then multiplies the relative position by the number of pixels per block. This will then give you a cursor position.
Then, it takes that cursor position and checks it against a list of position and size values. These position and size values are for the buttons. If the cursor are within the proper range of these values, then it will check if the player is clicking. If the player is clicking, then it will finally return true.
After it returns true, then it will run a function that controls the position of the block depending on what block was returned.
This is a bit of a general explanation and doesn't explain the full dynamics of the code, which is why I specified to look at the source code on Github as it does show the full dynamics of the code.
@@bndlett8752 Thanks! / Спасибо!
wow cool
well, as a logic pro, i know that it is easy to make this.
It is.
You can make one using your actual cursor.
Please do elaborate on what you mean with this
@@bndlett8752Use shootX and shootY
Here are the pros and cons to using an arc:
Pros:
1. Only one person can try to control the touchscreen at a time
2. An arc doesn't need to be powered (and therefore, shoot) in order for it's click to be registered, which is overall more convenient for the user.
Cons:
1. Someone can just force you out of the arc via deleting it, which will basically remove your authority of the screen until you get back into the arc.
2. You need to actually get into the arc first. This isn't as much of an issue on Erekir sandbox maps, but it does cause issues on Serpulo sandbox maps. Especially whenever the schematic is placed a decent distance away from the core.
I am willing to deal with the cons in order to have the pros.
@@bndlett8752 Shootx and shooty can also only have one person at a time, and it does not need power either
@@someone4229 until someone moves in closer and the authority is switched. The issue is primarily with ensured authority. Generally speaking, I'd say that arcs will provide more "ensured authority."