Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Quick Links
Categories
- 7.8K All Categories
- 11 Help with translations
- 4.2K General questions
- 107 Roadmap
- 358 Game & application design
- 316 Plugins
- 70 User experience
- 75 Marketplace
- 291 Code snippets
- 34 Building a team?
- 269 Suggestions & requests
- 352 Announce your apps made with Gideros.
- 90 Step by step tutorials
- 668 Bugs and issues
- 195 Introduce yourself
- 239 Announcements
- 106 Forum talk
- 404 Relax cafe
Comments
Beside this, I have to admit that Corona API is really easy to use and contains many useful shortcuts for game makers. Gideros could be improved somewhat along those lines.
Likes: MoKaLux, keszegh, oleg, SinisterSoft, plicatibu, Apollo14, talis, dreiko65
https://deluxepixel.com
http://hieroglyphe.net/gideros/CoronaCannon/
Original game: https://coronalabs.com/blog/2016/02/02/corona-cannon-a-new-corona-sdk-sample-game/
No changes in original code, just a bunch of files added to translate corona calls to Gideros calls. This is just a proof of concept, I only implemented things that were used by this sample game, but it covers many aspects already, from core graphics to physics.
Cherry on the cake: this is an HTML export, which Corona doesn't support officially it seems (it is in beta...).
Likes: talis, oleg, SinisterSoft, plicatibu, MoKaLux, vitalitymobile
as a sidenote, after a while i managed to win a round and then i got this error (upon next level load i think):
Fragmenter - animated loop machine and IKONOMIKON - the memory game
Likes: antix, vitalitymobile
Likes: SinisterSoft, MoKaLux
https://forums.solar2d.com/
Fragmenter - animated loop machine and IKONOMIKON - the memory game
https://deluxepixel.com
also, they seem to be behind gideros in many aspects, html export, metal support, proven history of going open-source, among others.
their user base may be still much bigger on the other hand.
Likes: SinisterSoft, oleg
Fragmenter - animated loop machine and IKONOMIKON - the memory game
Likes: hgy29, keszegh
https://deluxepixel.com
Fragmenter - animated loop machine and IKONOMIKON - the memory game
https://deluxepixel.com
https://deluxepixel.com
Likes: SinisterSoft
Fragmenter - animated loop machine and IKONOMIKON - the memory game
They may agree that it would be better to team up Corona+Gideros.
"What one programmer can do in one month, two programmers can do in two months." - Fred Brooks
“The more you do coding stuff, the better you get at it.” - Aristotle (322 BC)
https://deluxepixel.com
https://forums.solar2d.com/t/may-1st-deadline-where-are-we/350919/9
I suggested that a good first step may to to establish some kind of common plugin system. That would benefit both SDKs.
Likes: keszegh
https://deluxepixel.com
Fragmenter - animated loop machine and IKONOMIKON - the memory game
https://deluxepixel.com
I just wanted to come here since it was linked in the Solar2D forums to say a few things. My tone can be a bit harsh but it is with love for games and open source.
The things I am not understanding are who, what, why and when?
Who does it benefit that Solar2D developers switch to Gideros? It benefits Gideros.
What does Gideros offer that Solar2D doesnt? It sure isnt clear and visually pleasant docs, unique platforms (like Switch) or new opportunities? Metal, AndroidX and better HTML5 builds?
Why would anyone want to switch to develop their existing Solar2D game on a "translation layer"? And more bugs and less performance ? And time to learn a new engine that sort of does the same but not quite? Count me in!
When how soon would everything work? How many months would Solar2D devs need to wait for everything that they need to be added to Gideros? If it takes several months then by that time Solar2D may already support Metal and AndroidX plus have other improvements.
If all that Solar2D needs is Metal, AndroidX and better emscripten HTML5 builds, then it would be less work to add them to Solar2D than to add everything that it offers to Gideros.
Everybody likes the SDK that they use otherwise they would change. If you want people to change and abandon their SDK then you must have a pretty good sales pitch. So far the pitch is "I have used Solar2D/Gideros for a long time and I want other people to use it too!" also Gideros doesnt look as good as Solar2D. Even if that is only on the surface, it matters. Also you dont have guarantees for Gideros either. If Solar2D fails, people prolly go for Unity or Godot.
So here is my final question: why wont you all change to Solar2D once all its code is open source? I'm not making a sales pitch for Solar2D, I'm just asking why stick with Gideros and ask others to abandon Solar2D and not the other way around if Solar2D developer count is much bigger?
Likes: MoKaLux, SinisterSoft
i will give some partial answers (which are all reflecting only my opinion).
so the idea to 'join forces' here on the forum came when the future of solar2d/corona became shaky. then @hgy29 quickly made a prototype translation layer as a proof of concept that shows that it's relatively easy to make such a thing that fully works. this would mean that a solar2d code can be complied without change using gideros. this could save the ass of solar2d developers who are mid-project when solar2d ceases to be developed.
currently, the future of solar2d looks a bit better, having supported its sole developer, but what happens in long term is still not clear i guess. gideros community has been in this same position many years ago, so i/we can relate to this state of worry. my opinion is that gideros came out well and is on a steady open-source track where even without huge financial support it keeps to be maintained and improved by enthusiastic and good developers.
in short, now using gideros as a back-end may not seem to be such an optimal solution for a solar2d developer, it's just simpler if solar2d keeps being worked on. clearly e.g. plugins would not work out-of-the box etc (although plugin code is usually a small fragment of all code, so it's relatively easy to switch to gideros plugins while leaving the rest of the code as it is)
from a financial point of view however i think that only adding all the features that are planned for solar2d and are already in gideros is 10 times more time (and money) than writing the translation layer (like i think adding html is at least 5000 usd while i think for 500 usd a perfect translation layer could be added, but that's only my guess). considering that solar2d's sole developer seems to communicate that he only works on solar2d if there is enough income, that may be something which can become an interesting aspect.
about your critiques to gideros, it's mostly the looks, which is clearly lacking, given our small user base, especially compared to corona2d who must have spent considerable money on marketing before closing down. but believe me under the hood it's a very fast and stable framework, has lua's simplicity and advantages that you know already from solar2d. also i think even with a translation layer it won't be slower than solar2d. and has very simple export to android, and many other cool features which others may detail more, my post is already long.
Who does it benefit that Solar2D developers switch to Gideros?:
Our benefit form merging/working together is clearly a bigger user-base which makes the whole thing more fun and more future-proof. i think solar2d users have much more benefit in fact, a safe-guard for harsher times and a lot of extra features 'for free'.
What does Gideros offer that Solar2D doesnt?:
Metal and better HTML5 builds, sure. i don't really know solar2d that well, so others can tell everything else that is better. these are good, i don't know how it relates to solar2d though: i'd say gideros export is very simple to android, has a track record of being open-source and self-contained, good debug features (using zerobrane studio especially), shaders, rudimentary 3d (but with all the possibilities it gives).
Why would anyone want to switch to develop their existing Solar2D game on a "translation layer"? And more bugs and less performance ? And time to learn a new engine that sort of does the same but not quite? Count me in!:
I don't think it would give more bugs, nor less performance. you don't need to learn much as you'd use the solar2d api, that's what the translation layer is for.
When how soon would everything work? How many months would Solar2D devs need to wait for everything that they need to be added to Gideros? If it takes several months then by that time Solar2D may already support Metal and AndroidX plus have other improvements.
I think if there would be incentive (money, enthusiasm) then @hgy29 and other gideros developers could make such a layer in a fragment of time/money of what it will take to add metal etc to solar2d. but of course it's just my guess by evaluating how complicated this seems to be.
All in all, i hope solar2d will be kept being developed for a long time and this merging will be only an opportunity to you guys and not a necessity. it would be great btw if this discussion would reach more solar2d developers, as it aims them more than it aims gideros developers, i think.
Likes: SinisterSoft
Fragmenter - animated loop machine and IKONOMIKON - the memory game
Thanks for sharing your thought! I can't see any reason for Solar2D users to switch to Gideros without a bit of reluctancy. Like you said everybody prefer the SDK they are used to work with.
However Solar2D became open source (and changed its name), and while I am glad to notice that it managed to get funded so far, the team behind it is now on its own and the hardest part just begun. Gideros, on the other hand, has been open source for 8 years now, and we know how difficult it can be.
Some ex-Corona SDK users may be afraid of the future of Solar2D, and they may want to have a look at what Gideros has to offer. Actually both SDK functionnality are very similar, as I discovered when writing a translation layer prrof of concept. If enough people want to work on that layer, that would give Solar2D users an emergency solution in case the worst happen with Solar2D.
Your point about the 'When' is very interesting: in open source projects, you can't expect something to be done for you. If no-one else cares, then the online way to have something done is to do it yourself.
Likes: SinisterSoft
Fragmenter - animated loop machine and IKONOMIKON - the memory game
I can't post links, so here's the first paragraph from Android Developer portal:
"Artifacts within the androidx namespace comprise the Android Jetpack libraries. Like the Support Library, libraries in theandroidx namespace ship separately from the Android platform and provide backward compatibility across Android releases."
I think the rounded corners on Android are also there.
Likes: SinisterSoft
https://play.google.com/store/apps/developer?id=razorback456
мій блог по гідерос https://simartinfo.blogspot.com
Слава Україні!
New plugins can be written using kotlin and/or androidX.
I learned about the crown before I learned about Gideros
And I started with the corona
Before that I used unity3d
I switched to Gideros because it looks better than the Corona.
I conducted an experiment by making the same mini-games in the Corona and in Gideros.
Game made in Gideros made in 15 minutes, brought me $ 8000 game made in CORONA brought nothing. The same game, the same store, just a game of Gideros, was a couple of megabytes smaller ...
Unity is a good engine, but it is not suitable for niche games running on non-top smartphones ..
Likes: SinisterSoft
https://play.google.com/store/apps/developer?id=razorback456
мій блог по гідерос https://simartinfo.blogspot.com
Слава Україні!
I think that having an alternative that is at least semi-compatible 'out there' is good for both SDKs. It means you have confidence to carry on with the system you are using knowing that there is a solution available should the worst happen.
Btw, when I first started with Lua I tried out both Corona and Gideros - when both were paid platforms. Back then it struck me how it seems the Corona team didn't seem to know how games worked (back in the old day), but the Gideros team did. A simple example is tilemaps - they are a cornerstone of the 'old school' games industry - you simply have to have them. Gideros had them from the beginning, I'm unsure if Corona still doesn't have them or not, but when I used it people were asking for them but it fell on deaf ears. Another example is bit manipulation - people in the Corona forums have been asking for binary operations for ages - still the Corona version of Lua still doesn't have them (you have to use a Lua library). With Gideros they were added years ago, along with loads of other operators and enhancements that are useful for coding games.
I agree that Solar2D documentation is much better than the Gideros docs, the Corona website is also prettier. Don't forget though that Gideros has been open source for years (with no investment), so the users have to put the effort in to help keep things current. Nobody likes writing docs, but recently we have been trying to switch things up and our documentation is starting to look much better than it did.
If you look at the thread on the Solar2D forum you will see that I also agreed that the two maybe shouldn't merge, but possibly some kind of agreement on how plugins could be compatible with each other could be arranged. That would benefit both SDKs as usually two heads are better than one.
Likes: oleg
https://deluxepixel.com
Likes: SinisterSoft
Fragmenter - animated loop machine and IKONOMIKON - the memory game