#104326 - Lynx - Thu Sep 28, 2006 2:36 am
I started this thread because of the discussion that took over ThaKilla's DS Blue app thread.
So.. now, being "on topic"..
It doesn't matter if the programmers are getting paid or not, competition is still a good thing. It works with pretty much everything. If people were just making these programs for themselves, why would they release it at all? Well, because they want to share their hard work. Well, they also like to get recognition for the hard work they have done. So, if there are two apps that do the same job.. wouldn't you want your app to be the "better" app? Wouldn't that push you a little harder?
Maybe I'm way off base, but I believe that a lot of people release homebrew with recognition in mind. Look what I can do.. check out how awesome my app/game is.. How many game makers actually spend as much time playing their game as they did creating it? I'm sure not many. And they don't just do it to learn, or they wouldn't release the game/app at all, as what does the rest of us care what they have learned?
Just as I feel good when you google 'ds homebrew' and my site comes up at the top (I don't get paid from it), they feel good about us praising their hard work.
Competition is good.
_________________
NDS Homebrew Roms & Reviews
#104328 - tepples - Thu Sep 28, 2006 2:41 am
Competition can work in the world of free software. Just look at GNOME vs. KDE[1] or Firefox vs. Konqueror or XMMS vs. Amarok.
[1] No, not the abortive attempt at a Panel Action Bingo clone for NES that never ran successfully on hardware.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#104345 - kevinc - Thu Sep 28, 2006 5:46 am
I agree with tepples on the "open source" requirement. Both programs with similar functionality can compete with each other, but they can't really "collaborate" unless they can learn from each other. For that source code is certainly a requirement.
_________________
http://akzeac.blogspot.com
#104350 - HyperHacker - Thu Sep 28, 2006 6:56 am
| Lynx wrote: |
| How many game makers actually spend as much time playing their game as they did creating it? I'm sure not many. And they don't just do it to learn, or they wouldn't release the game/app at all, as what does the rest of us care what they have learned? |
If you never release your game, how do you know if it's any good? Part of learning how to make a game is learning how to get it known and deal with any criticisms or suggestions players have.
_________________
I'm a PSP hacker now, but I still <3 DS.
#104354 - Mr. Picklesworth - Thu Sep 28, 2006 7:19 am
There's all sorts of competition.
Friendly competition is great, and KDE vs. Gnome is fine, since they can learn from each other due to the whole open source thing.
I felt kind of bad recently because I had started developing something amazing (excuse my complete lack of modesty) to build on the concepts in Toribash, but it eventually shaped up to be its own unique idea with nothing at all in common with Toribash.
Without the initial urge to compete, OpenWorlds (the first in a long line of do-it-yourself software) would never have happened in the ideal future :)
Anyway, it's up to the developers in the end.
Competition is both good and bad, and in my opinion it is best if both programs find their own place. It prevents disappointment on both ends and it can spark the imagination.
DSBlue vs. DSOrganize... well, we'll just have to wait and see.
I like them both, so in the ideal world I'd like to see all their strengths combined into one but I realize that can be difficult.
Over here, though, it's not really competition as much as it is just two people building neat software and seeing what they can do with it. The only real competition is in my decision for which one I will use for my calendar once DSBlue is cleaned up :P
_________________
Thanks!
MKDS Friend Code: 511165-679586
MP:H Friend Code: 2105 2377 6896
Last edited by Mr. Picklesworth on Thu Sep 28, 2006 5:55 pm; edited 1 time in total
#104357 - Lick - Thu Sep 28, 2006 9:17 am
I should really start working on Dii, so you can pick between DSO, DSB and Dii!! :P
[/joke]
Seriously, homebrew development is mostly done by hobbyists that enjoy the freedom they get creating something useful. The word 'freedom' is the key of that sentence. Co-operation takes away the freedom and brings in a lot of obligations and deadlines. It's often much easier to work alone, in the developers point of view.
- Lick
_________________
http://licklick.wordpress.com
#104361 - Mrshlee - Thu Sep 28, 2006 10:37 am
Does anyone know an opensource project manager? like a little Sourceforge.
Something that would allow someone to start a project.. they can activelly work on it while collaborating with anyone else whom is interested.
Developers sometimes like to work alone but letting people jump in with updates here and there.. continue working on older/dumped projects.
Grab a whole bunch of bored devs and tweak your heart out ;)
_________________
MrShlee.com
Projects
Dev-Scene
MyTechpedia
#104365 - jester - Thu Sep 28, 2006 12:21 pm
Lick thats cool what are planning to work on once you receieve your money from SCDev?
_________________
If anyone needs a dragonball online email me @ aaronthejester@hotmail.com
#104368 - Lick - Thu Sep 28, 2006 12:24 pm
Hey jester! I'm probably going to work on DSLiveFTP or DSLiveHotspots (name is not definite yet). The first is an FTP client, and the latter will be an AP configurating tool and/or library (that other developers can use).
- Lick
_________________
http://licklick.wordpress.com
#104372 - jester - Thu Sep 28, 2006 12:28 pm
Excellent i look forward to this news!
_________________
If anyone needs a dragonball online email me @ aaronthejester@hotmail.com
#104390 - josath - Thu Sep 28, 2006 4:43 pm
| Lick wrote: |
Hey jester! I'm probably going to work on DSLiveFTP or DSLiveHotspots (name is not definite yet). The first is an FTP client, and the latter will be an AP configurating tool and/or library (that other developers can use).
- Lick |
Ok, we're expecting some AWESOME stuff from you, now that you've got the ~$400 from the raffle. That's like 20 hours of work at $20/hr. So get to it! :P
#104399 - DeVS - Thu Sep 28, 2006 6:22 pm
lol. I made it clear to Lick that this raffle was done as a thank you for what he has already done not to do more. I told him if he decided to never relase another app or update to DSLiveWeather I would be 100% satisfied with what he has given us and the raffle is just a thank you for that effort. If it encourges him to do more then thats just an added bonus for the rest of us, but Lick has no obligation because of the raffle.
I also think competition is a good motivator for creating something. I think DSBlue is great and am excited to see what he comes up with next to improve. The more homebrew apps/games the better for the rest of us,lol.
#104402 - josath - Thu Sep 28, 2006 6:48 pm
It's your money, and I can't tell you what to do with it, and I'm sure Lick deserves it, and will continue to make great things, but in my opinion, a better use of money would be to sponser a compo. Encourage many people to make homebrew VS encourage one person (except I guess you say the money wasn't meant to encourage him, but you get my point).
#104403 - Mrshlee - Thu Sep 28, 2006 6:50 pm
| DeVS wrote: |
| lol. I made it clear to Lick that this raffle was done as a thank you for what he has already done not to do more. I told him if he decided to never relase another app or update to DSLiveWeather I would be 100% satisfied with what he has given us and the raffle is just a thank you for that effort. If it encourges him to do more then thats just an added bonus for the rest of us, but Lick has no obligation because of the raffle. |
I highly recommend Wintermute for the next raffle "developer"..
_________________
MrShlee.com
Projects
Dev-Scene
MyTechpedia
#104408 - DeVS - Thu Sep 28, 2006 7:54 pm
The next raffle will be hosted by another site (not sure who yet, many have requested to do it next and im hoping to make it a rotating thing each raffle being held by a new site). I will let you know who is doing it next that way everyone can decided who to do it for. And it's not my money,lol, it's the accumulation of many people from many sites who contributed it so im always open for suggestions and ideas on how we can give back to these developers. I said before that I know people don't always have money on hand to be able to contribute like this, but even just a "Thank you" can go along ways and alot of the useres of these homebrew apps/games can't even take the time to say that much.
#104414 - OOPMan - Thu Sep 28, 2006 9:23 pm
Hmmmm, I would personally love to see more homebrew collaboration. It's extremely sad to me that a lot of homebrew projects (In particular some of the promising ones that have died) have remained closed source, mkaing continued development difficult...
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI
You can find my NDS homebrew projects here...
#104442 - Lynx - Fri Sep 29, 2006 5:56 am
| Mrshlee wrote: |
| Does anyone know an opensource project manager? like a little Sourceforge. |
The Sourceforge site is opensource, so you could make one exactly like it.
| OOPMan wrote: |
| have remained closed source, mkaing continued development difficult... |
Even the ones that have released source, didn't save the project, or show any continuation. I wish people would stop saying "releasing the source will allow a project to continue" as it just isn't true. Sure, if the community is lucky, someone might pick up the project and continue it, but I believe if you research, there is a lot more released source projects that have died then that have stayed alive.
_________________
NDS Homebrew Roms & Reviews
#104474 - Darkflame - Fri Sep 29, 2006 3:35 pm
Sorry, missed this thread ;x
Yes, open sourcecode isnt the answere, it merely helps a lot.
Imo, co-operation is a must now for us too truely start to push the potential applications for the DS hardware.
The first thing we need to do is establish standards.
To help applications to work together and provide a more seamless expirence.
Random ideas:
*standard folders? (/data ect)
*standard Ram usage?
--for exchanging a file path? (so a Rom could trigger an emulator to load, then the emulator to automaticaly load the rom)
--standard clipboard?
--exchange of playlist/music info. (ok, crazy idea here, but maybe if your playing music in one app, it could pass the track name and position over too another app you run to give the illusion of multi-tasking)
* Plugins (allready partly done with moonshell)
-- Letting apps decode/play music easily. (so anyone makeing a game could just use an Ogg without worrying too much)
-- Decodeing image formats.
-- Retrieveing web data. (ie, something that takes info from a url and dumps it in ram....a generic plugin like this would be usefull to lots of people no? )
These are just random ideas, they could all be worthless, but I still am very strongly for the principle of working together, and reusing as much code and resources as possible.
If nothing else, it would give us a bit more space on our flash cards ;)
_________________
Darkflames Reviews --
Make your own at;
Rateoholic:Reviews for anything, by anyone.
#104490 - OOPMan - Fri Sep 29, 2006 6:06 pm
*sigh*
I never said open-source was the answer...
I just said it would be better that the source was available rather than not.
A closed source project that dies has no chance of being resurrected or used for anything. An open source one has some chance of being resurrected or at the very least can provide interested parties with actual code to look at.
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI
You can find my NDS homebrew projects here...
#104494 - josath - Fri Sep 29, 2006 6:59 pm
| OOPMan wrote: |
*sigh*
I never said open-source was the answer...
I just said it would be better that the source was available rather than not.
A closed source project that dies has no chance of being resurrected or used for anything. An open source one has some chance of being resurrected or at the very least can provide interested parties with actual code to look at. |
I think if someone is interested in restarting a project, they can contact the original author. Open source would make it slightly easier, but I agree for most homebrew stuff, being open source doesn't really make too much of a difference. It is important in some places though (libraries, code that was meant to be reused, etc)
#104496 - Darkflame - Fri Sep 29, 2006 7:39 pm
We all agree Open Source is good, but not the only answere right?
So I dont see the point in debateing that further.
_________________
Darkflames Reviews --
Make your own at;
Rateoholic:Reviews for anything, by anyone.
#104500 - tepples - Fri Sep 29, 2006 8:45 pm
| josath wrote: |
| I think if someone is interested in restarting a project, they can contact the original author. |
And have every e-mail bounce. A lot of authors seem to disappear without a trace.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#104507 - Lynx - Fri Sep 29, 2006 9:48 pm
Yeah, but if they didn't release the source, and didn't use an e-mail address for the project the normally check, then they probably wouldn't give out the source anyway (for whatever personal reason).
I love open source, it's just not the answer to everything..
I'm also for collaboration, and we have seen some very good homebrew releases that had collaboration.. GFX artist, SFX artist, etc. But, if one person is working on a project it normally means they want it to stay that way.
_________________
NDS Homebrew Roms & Reviews
#104508 - tepples - Fri Sep 29, 2006 10:25 pm
| Lynx wrote: |
| Yeah, but if they didn't release the source, and didn't use an e-mail address for the project the normally check, then they probably wouldn't give out the source anyway (for whatever personal reason).. |
Some people who mean well use an address provided by a university but lose it after graduating or after switching ISPs.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#104529 - Mrshlee - Sat Sep 30, 2006 5:12 am
if someone can think of a good way to handle code/source.. apart from what I'm doing and just keeping it archieved
_________________
MrShlee.com
Projects
Dev-Scene
MyTechpedia
#104536 - OOPMan - Sat Sep 30, 2006 9:07 am
I think that in a relatively small community open-sourcing the projects can be useful in that it provides a lot of example code for new-comers to look at and play around with.
Cutting your teeth is all well and find but it has it's negative side-effects too...
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI
You can find my NDS homebrew projects here...
#104544 - Lick - Sat Sep 30, 2006 11:18 am
Darkflame: Those "standards" may sound right for you, but limiting for others. Please let the developers decide when they want to co-operate. Besides co-operation doesn't always have to be working in a team, it can also be sharing of information and codebits with each other.
Homebrew devs are not slaves of "Homebrew Lord" or employees of "HomebrewSoft Ltd." You have to understand that sometimes, to you it might seem like we're reinventing the wheel, but actually, we have a lot of personal FUN while we do that. We learn much about the system and how to code the best solution (I belive this is the main point to handheld homebrew). If you tell us to co-operate and leave some interesting stuff to others, then it will take away the fun.
Let us be.
It's not that I don't see your point, I totally see your point. I even agree with it, but not in this situation.
- Lick
_________________
http://licklick.wordpress.com
#104560 - Darkflame - Sat Sep 30, 2006 12:28 pm
| Lick wrote: |
| Darkflame: Those "standards" may sound right for you, but limiting for others. |
I said:
| Quote: |
| These are just random ideas, they could all be worthless |
They were an example of the sort of things that could be agreed apon, not a dictation of what has to be.
I hoped to start a discusion on what would be good ideas as standards to establish.
Purhapes we could even come up with common code people should put in their apps if they wish. (Eg, "Standard Standby Code" and "Standard Return to Multiboot" ).
It would be nice for the lesser-skilled (like me) to have these sorts of things.
I also think, a heck of a low of homebrewers would start to use these things if they are easy and no dissadvantages.
I dont think many developers have intentional thought "no a standby would not be a good idea in my app".
Its more a case, imo, of "I dont have time to look up/work out how to get a good standby..its not a fun thing to do".
| Quote: |
| Besides co-operation doesn't always have to be working in a team, it can also be sharing of information and codebits with each other. |
Which was my point.
I dont expect all projects to be made by a team, but I do expect people to help and share information a lot more then is now.
People arnt not shareing stuff because they dont want too, its more because theres no organised, easy, way too do it.
People dont have the *option* of conforming to standards or to share ideas, or too reuse resources, because no one has sat down and discused it.
If some standards are discused and agreed it dosnt mean every one has too 100% conform too it.
It merely means its there for those that do wish too participate.
It also means people that cant donate much time (like me) can still build apon the work of others and contribute something.
In many ways having a few standards, and starting to work towards plugins means a lot more can be done by individuals.
If you dont want co-operation, thats fine, but I dont see any point in argueing against it. If you dont believe you would ever use homebrew standards, then it dosnt make any difference too you anyway.
_________________
Darkflames Reviews --
Make your own at;
Rateoholic:Reviews for anything, by anyone.
#104568 - Lick - Sat Sep 30, 2006 1:23 pm
I'm surprised that you say that we don't spread enough information. Dude, look at this forum, look at the IRC channel. Ask, and you shall in 98% of the time get an answer.
And about the idea of standards, I still don't think the homebrew scene will work that way. If you want to try it, good luck!
- Lick
_________________
http://licklick.wordpress.com
#104574 - Lynx - Sat Sep 30, 2006 3:55 pm
| Mrshlee wrote: |
| if someone can think of a good way to handle code/source.. apart from what I'm doing and just keeping it archieved |
CVS or SVN. Both good tools to learn, not only for homebrew, for in the "professional" programming world as well. SVN has become more the standard for "today" but a lot of companies still use CVS.
CVS
SVN
_________________
NDS Homebrew Roms & Reviews
#104585 - OOPMan - Sat Sep 30, 2006 5:44 pm
| Darkflame wrote: |
Purhapes we could even come up with common code people should put in their apps if they wish. (Eg, "Standard Standby Code" and "Standard Return to Multiboot" ).
It would be nice for the lesser-skilled (like me) to have these sorts of things.
I also think, a heck of a low of homebrewers would start to use these things if they are easy and no dissadvantages.
I dont think many developers have intentional thought "no a standby would not be a good idea in my app".
Its more a case, imo, of "I dont have time to look up/work out how to get a good standby..its not a fun thing to do". |
I agree with this. This is one of the reasons I'm working on getting a proper thread library ported to the DS. Sure, I plan to use it, but I'm sure other people will too, if it's available.
While it can be fun to re-invent the wheel, it's not always a good thing productivity-wise. I'm not saying we should all be busy-bee coders, churning out homebrew app after homebrew app, but it would be nice to see a few more standard libraries for NDS development above and beyond lthe fat lib, wifi lib and basic libnds (Which is really the underlying layer that ensures we don't spend all our time wrangling with ARM assembler code [Which can be fun, but can also delay things a lot])...
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI
You can find my NDS homebrew projects here...
#104588 - kevinc - Sat Sep 30, 2006 6:09 pm
| OOPMan wrote: |
| I agree with this. This is one of the reasons I'm working on getting a proper thread library ported to the DS. Sure, I plan to use it, but I'm sure other people will too, if it's available. |
Oh, please. If it works well, I promise I'D use it.
| Quote: |
but it would be nice to see a few more standard libraries for NDS development above and beyond lthe fat lib, wifi lib and basic libnds (Which is really the underlying layer that ensures we don't spend all our time wrangling with ARM assembler code [Which can be fun, but can also delay things a lot])... |
People seem to like to access the hardware directly using libnds. That's why, I think, there's so much resistance to the concept of PALIB.
_________________
http://akzeac.blogspot.com
#104877 - Lynx - Tue Oct 03, 2006 7:22 pm
PALib is for someone who just want's to write a program that runs on the NDS.. NDS lib is for the person who wants to know the ins and outs of the hardware and write software.
I know both types of people, and neither are "right" or "wrong" just different opinions. I know there are a lot of PALib bashers out there, but that is only because they are not willing to understand how some people don't want to spend as much time as they do understanding the hardware that they could be using to write the actual game code. Is PALib perfect? Of couse not. Is NDSLib perfect? I doubt it. There is no reason both can't live happily together.
_________________
NDS Homebrew Roms & Reviews
#104894 - Sausage Boy - Tue Oct 03, 2006 9:11 pm
...that was the single most sane post about that subject, or pretty much any subject, in a long time.
_________________
"no offense, but this is the gayest game ever"
#104905 - Darkflame - Wed Oct 04, 2006 1:05 am
| Lick wrote: |
I'm surprised that you say that we don't spread enough information. Dude, look at this forum, look at the IRC channel. Ask, and you shall in 98% of the time get an answer.
And about the idea of standards, I still don't think the homebrew scene will work that way. If you want to try it, good luck!
- Lick |
a) Not quite the same thing, theres many helpfull people about,sure.
But thats quite different from having a little libaury of usefull codes we can all add too and take from.
Also, having lots of people asking the same basic questions can get annoying ;)
(not to mention standard code can be optimised)
b) Why not? Works for PC's.
Dont you think it would be handy to have the equilivent of "dll" files for the ds ?
I think we could get some interesting programs building up if we did that.
eg.
Person A makes a wireless download program
Person B makes a Jpeg reader
Person C uses A and B's dll's to make a program that retrieves a map of your local area and downloads it (say, using google map).
Person D thinks "hay thats cool" and then uses the same map as a texture for a little Glider game, so people can fly over their own area.
You see, none of those people have too even talk of communicate, but they can build off eachothers work.
It dosnt stop anyone from doing whatever they want, they can leave the files well alone. But for those that just want too get to an end they can make far more impressive things easier.
A side effect too, is that some programs will be a bit smaller.
Id love to "give it a try", but I dont have enough knowledge.
And you cant have a guy establish standards on his own even if I did...its gota be discused a bit, work out the best way to do stuff :)
_________________
Darkflames Reviews --
Make your own at;
Rateoholic:Reviews for anything, by anyone.
#104919 - Turambar - Wed Oct 04, 2006 5:53 am
| Darkflame wrote: |
Why not? Works for PC's.
Dont you think it would be handy to have the equilivent of "dll" files for the ds ?
I think we could get some interesting programs building up if we did that.
eg.
Person A makes a wireless download program
Person B makes a Jpeg reader
Person C uses A and B's dll's to make a program that retrieves a map of your local area and downloads it (say, using google map).
Person D thinks "hay thats cool" and then uses the same map as a texture for a little Glider game, so people can fly over their own area.
You see, none of those people have too even talk of communicate, but they can build off eachothers work.
It dosnt stop anyone from doing whatever they want, they can leave the files well alone. But for those that just want too get to an end they can make far more impressive things easier.
A side effect too, is that some programs will be a bit smaller.
Id love to "give it a try", but I dont have enough knowledge.
And you cant have a guy establish standards on his own even if I did...its gota be discused a bit, work out the best way to do stuff :) |
You don't need to build an extensive dll-like system, you can already do that with libs. Dlls are only usefull (in a non-multitasking system) if you don't want your code to be open-source.
#104948 - Lick - Wed Oct 04, 2006 3:43 pm
From the looks of it, you haven't coded for the DS platform at all as you have no idea how it works and how bad hacking it would be if we would implement a DLL system. The best way to share code is by open sourcing the code.
If you can't even inject some code (like libjpg, dswifi) into your own project and you need people to write a plug-in system for you, then you just aren't cut for homebrew.
The examples you mentioned aren't hard if the programmer is at LEAST a BIT experienced. Just implement DsWifi and some imaging library you find on the internet.
You aren't describing "collaboration", you're describing PALib. =/
- Lick
_________________
http://licklick.wordpress.com
#104949 - kevinc - Wed Oct 04, 2006 3:59 pm
I've been researching a bit too about shared libs. Oh, it would have its advantages; for example, no need to recompile the program if the wifi lib got updates. And the programs would be much smaller. Though I don't think it'd be worth the trouble. Infantile Paralysiser has implemented that in part, check out the Moonshell sources.
| Lick wrote: |
| The best way to share code is by open sourcing the code. |
Then why don't you share? :]
_________________
http://akzeac.blogspot.com
#104950 - Lick - Wed Oct 04, 2006 4:35 pm
I have already shared a decent amount of code. But if you mean DSLiveWeather, well, nothing but hard work, what's there to share? Yes I could opensource the project, but I didn't because all the helpful code is already public and it would only be good for people who like to fork or continue when I'm stopping so I see no need to opensource it, yet.
If you wonder how I did some stuff that's NOT covered in the demo or blog, then ask me.
_________________
http://licklick.wordpress.com
#105068 - Darkflame - Thu Oct 05, 2006 5:47 pm
Dll's was only used to mean "shared subroutines", incidently, it seemed the closest thing to what I was thinking off.
| Quote: |
| From the looks of it, you haven't coded for the DS platform at all as you have no idea how it works and how bad hacking it would be if we would implement a DLL system. The best way to share code is by open sourcing the code. |
I have written a few minor tests and programs, but I dont have much time. (eg.www.darkflame.co.uk/gravity.nds )
And not everyone wants to share open source. Personaly, I would, but I have nothing against those that dont. Some people might want to release closed-source dll's thats still useable. (say, a encrpytion techique)
Its also completely impractical to have to ask person X,Y,Z every time you want a little snipet of code to help you. Some people would get, quite rightly, fed up with being asked for things.
I dont get why you seem so opposed to even the slightest idea of making it easier for people to help themselves.
| Quote: |
If you can't even inject some code (like libjpg, dswifi) into your own project and you need people to write a plug-in system for you, then you just aren't cut for homebrew.
The examples you mentioned aren't hard if the programmer is at LEAST a BIT experienced. Just implement DsWifi and some imaging library you find on the internet. |
Ok, ignoreing your rude/agressive attitude:
Its a mater of time.
Some people, indeed, most people, dont have a lot of time to spend on homebrew but still enjoy doing it.
Also, as products get more complicated the number of these things you find easy to do multiplys upwards quickly.
And its not a case of "I want someone to write a plugin system for me"
Its a case of "I think a plugin system would help everyone in the community".
Personaly, I am actualy more likely to write small plugins rather then big projects.
| Quote: |
| I've been researching a bit too about shared libs. Oh, it would have its advantages; for example, no need to recompile the program if the wifi lib got updates. And the programs would be much smaller. Though I don't think it'd be worth the trouble. Infantile Paralysiser has implemented that in part, check out the Moonshell sources. |
Yes, moonshell seems to do it well...but for obvious reasons, its not documented so I dont think many people know even where to start if they wanted to use it for there own apps.
Some might call it "bad hacking", but whatever moonshell is doing seems to work fine, imo :)
Naturely, I think it is worth the trouble, not only for the point of seamless updateing, but also because it would let a lot more people do a lot more for a lot less effort.
It also lets people with less time contribute more.
When I code for the PC, I dont have to worry about getting source code for a "Save As" dialogue box, on simerla lines, I can see it being helpfull is DS coders also didnt have to worry about certain commonly used things things.
In short, I think it would kick-start homebrewers a bit more.
But *even if* "shared subroutine" functionality is impractical.
At the very least we should be getting a shared code-based.
My exact same example of the picture-being retrieved from the internet and used in a flying game, would indeed also work perfectly fine if we had some sort of code resource.
It would have to be easy access for all, and anyone can contribute.
I have used CLS a bit when I was using GLscene, it works fairly well, but I think a website would be better because more people will use and, and more people will "be aware" of it.
_________________
Darkflames Reviews --
Make your own at;
Rateoholic:Reviews for anything, by anyone.
#105076 - Lick - Thu Oct 05, 2006 6:26 pm
Well what is the difference with the thing you're describing and let's say.. Palib? And I get the feeling that you're unaware of the ability to compile cross-platform code for the DS too? There are so many useful existing libs you can include in your project.. Why rely on something foolish like a plug-in system?
_________________
http://licklick.wordpress.com
#105125 - HyperHacker - Fri Oct 06, 2006 7:58 am
There is an advantage to having some sort of file stored on the card containing precompiled commonly-used code, as opposed to copying that code at source level into each app: It cuts down filesize. You don't have copies of the code in each app. Plus you can update it and have those updates propogate to multiple programs.
_________________
I'm a PSP hacker now, but I still <3 DS.
#105163 - Lick - Fri Oct 06, 2006 2:48 pm
What if the card doesn't support FAT the way it should? (Or fatlib doesn't support that device)
Would the developers have to build a plugin-build and a no-plugin-build too? The no-plugin-build would never be built, because the developer relies on the plugin-system so much, he doesn't know how to code without. AND AS A RESULT, many end-users won't be able to run the file. But, if the no-plugin-build -IS- indeed built, then there wouldn't be a need for the plugin-build!
The cons simply and clearly outweigh the pros. There's nothing wrong about the current system, that's why you'll find so little support from the devs here, to change to a new system.
_________________
http://licklick.wordpress.com
#105184 - thoduv - Fri Oct 06, 2006 4:46 pm
By looking at Moonshell's sources, a plugin system is very easy to write. I had done it for Ndsim, and it worked *quite* well (except you can't access raw memory adresses from a plugin).
#105188 - Darkflame - Fri Oct 06, 2006 5:24 pm
| Quote: |
| By looking at Moonshell's sources, a plugin system is very easy to write. I had done it for Ndsim, and it worked *quite* well (except you can't access raw memory adresses from a plugin). |
Hmz..thats a shame about memory.
How does the plugin and the main code exchange data then?
I was hopeing files could swap data by simply putting things in a few agreed memory locations.
(the same way I hoped we could use file-extensions to trigger programs, saving the path to memory, which the prog then reads to load the correct file)
| Quote: |
| Well what is the difference with the thing you're describing and let's say.. Palib? And I get the feeling that you're unaware of the ability to compile cross-platform code for the DS too? There are so many useful existing libs you can include in your project.. Why rely on something foolish like a plug-in system? |
Why is it foolish when its used on non-portable platforms so commonly?
Also, of course cross-platform code can be compiled for the DS.
But that ignores DS-specific features and optimisation.
I am sure if a common code-base for the DS, a lot of it would be just ports or versions of code from other things. But it would still be a common collection of code tuned and garentied to work on the DS.
In short, it would still be very usefull.
Its still something that we could all build on and add too, so big-projects become easier.
One simple example is on almost all homebrew apps we have to restart the system whenever we want to return to our bootloader.
If there was a codebase people could use a generic "Run _Boot_.nds" for thier exit button the menu, I am sure we would see a lot more programs using it.
| Quote: |
| What if the card doesn't support FAT the way it should? (Or fatlib doesn't support that device) |
Well, this is a problem indeed.
Could we not, in theory, have (different) plugin code to work on a non-fat device, yet still reads the same actual plugins?
_________________
Darkflames Reviews --
Make your own at;
Rateoholic:Reviews for anything, by anyone.
#105213 - tepples - Fri Oct 06, 2006 8:04 pm
| Lick wrote: |
| What if the card doesn't support FAT the way it should? (Or fatlib doesn't support that device) |
In practice, it appears that most cards that do support DS mode but don't support FAT are new versions of SuperCard or M3, and they have 32 MiB of RAM to hold a ds.gba that has the plug-ins in a GBFS.
Or you could make the standard library into the main program, and user programs would become plug-ins.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#105249 - Lick - Sat Oct 07, 2006 12:12 am
How many "user-programs" will be made? This scene is simply too small and of course I'm a firm supporter of creativity and flexibility, however, it just isn't going to work as whatever you provide, people will not use it. There are even better alternatives alreayd available; DSLua and PALib are great for softcore programmers. Besides, no one is getting excited over developing the actual plug-ins. Has anyone (who codes) actually signed up for this project? I don't think so. Has anyone who codes applications signed up for making this project practical (implement the plug-in system), I don't think so.
It is a great idea, but in reality, it will never take off.
_________________
http://licklick.wordpress.com
#105251 - Sausage Boy - Sat Oct 07, 2006 12:28 am
I just don't understand the benefit of having plugins. The only real pro seems to be that it cuts down filesize, but really, no one will care if your program is 400kb smaller. It is useful on PC, mainly because you can upgrade the program without updating the library and vice versa, and you don't have to keep track of which program uses which version and stuff like that. On a portable platform, we don't have a huge multitasking operating system, we don't have to worry.
And what you're describing, as other people have pointed out, is already possible! It's called libraries! Libnds is a library, libfat is a library, the wifi library, libmad (mp3 decoding), tremor (ogg decoding), libraries for decoding images, PALib for making the coding easier, the list goes on and on. You're always reusing code when you make DS programs.
I believe you had an example:
| Quote: |
Person A makes a wireless download program
Person B makes a Jpeg reader
Person C uses A and B's dll's to make a program that retrieves a map of your local area and downloads it (say, using google map).
Person D thinks "hay thats cool" and then uses the same map as a texture for a little Glider game, so people can fly over their own area. |
Ok, person A makes a wireless download program (using the wifi library, perhaps?)
Person B makes a jpeg decoder (*coughlibjpegcough*)
Person C uses functions and snippets from the other people's code, and makes a program that retrieves a map of your local area and downloads it. No .dll's or plugins involved. Perhaps person A released his source under the GNU GPL, which would force person C to do so as well.
Person D looks and person C's source code, which he has of course released, GPL or not, and takes the parts he needs, and makes the glider game.
What I want you to realize is that everything you describe is already possible, and a system for module loading would mean more work for everyone, probably less effective and stable programs, and a big hassle, to include modules, to code the module system and to turn code into modules.
_________________
"no offense, but this is the gayest game ever"
#105261 - tepples - Sat Oct 07, 2006 2:44 am
| Sausage Boy wrote: |
| And what you're describing, as other people have pointed out, is already possible! It's called libraries! Libnds is a library, libfat is a library, the wifi library, libmad (mp3 decoding), tremor (ogg decoding), libraries for decoding images, PALib for making the coding easier, the list goes on and on. You're always reusing code when you make DS programs. |
What if I don't want to have libmad, mikmod, and tremor in the 4 MB memory (or, worse yet, the 64 KB reserved for the ARM7) at once? See overlays.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#105282 - Lick - Sat Oct 07, 2006 10:16 am
How much memory would the plug-in system need?
_________________
http://licklick.wordpress.com
#105306 - tepples - Sat Oct 07, 2006 4:09 pm
Probably not much. In Mac OS 1 through 9, every application was in an archive format called "resource fork", similar to Zip or GBFS. "Resources," or files in the resource fork, might contain a code segment (CODE), an icon (ICON, or ICN# if it had a transparency mask), a cursor shape (CURS), a text translation table (STR#), a dialog layout (DLOG/DITL), a menu layout (MBAR/MENU), or a list of file types that the app can open (BNDL/FREF). All code segments were compiled position independent (and thus were limited to 32 KB) and could be loaded or unloaded as needed. The parts of system software not stored in the firmware were also stored as resources in a file called "System" (fonts, default icons, etc). Plug-ins called "extensions", each with a resource fork containing a code segment (INIT), were executed at startup and could add or patch SWIs (the SWI table was in RAM on the Mac).
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#106547 - Darkflame - Fri Oct 20, 2006 1:54 pm
Plugings indeed give a big memory advantage ,but also an advantage of not worrying about sourcecode being released, or lisences.
A plugin can be used without having the source.
(not everyone not releaseing source code does it because they are evil, or want to make money, its often just practicality or an effort issue more)
But regardless of all this, there must be SOME things we can agree and move forward on?
For instance, can we not agree to set up a common code repository somewhere?
Return to multiboot, standby, and other commonly needed things could be put there?
(and slowly building a nice archieve of more interesting stuff too)
Also, How about agreeing on some system of placeing file-paths in a location in ram when one bit of software triggers another?
For instance,
So a Rom file could be run purely by selecting it...the extension tells the multibooter to run the emu, and the emu picks up the path from ram, and then auto-reads the rom.
On the surface, this dosnt seem that hard to me from a technical standapoint. Am I missing something?
Or is it purely a mater a social/agreement thing.
| Quote: |
Besides, no one is getting excited over developing the actual plug-ins. Has anyone (who codes) actually signed up for this project? I don't think so. Has anyone who codes applications signed up for making this project practical (implement the plug-in system), I don't think so.
It is a great idea, but in reality, it will never take off. |
Chicken and Egg.
No one has signed up or agreed because theres nothing to sign up too, we are just discuse ideas. Before anyone writers one line of code we would need to work out exactly what was going on.
And, depending on how hard it is, I already said I was much more likely to have time to write small plugins then big things.
Moonshell has already got a plugin system of sorts...its too bad theres a a bit of a langerage barrier, as his input in this would be very usefull.
_________________
Darkflames Reviews --
Make your own at;
Rateoholic:Reviews for anything, by anyone.
#106553 - Lick - Fri Oct 20, 2006 3:35 pm
The scene is small enough to find all the necessary code you need from the sourcecode released. This includes "Return to multiboot, standby, and other commonly needed things".
Also remember, among the users, there will be lovers and haters. Just like with PALib.
Anyway, I'll say it again: I wish it succeeds, good luck!
_________________
http://licklick.wordpress.com
#106564 - tepples - Fri Oct 20, 2006 5:44 pm
| Lick wrote: |
| The scene is small enough to find all the necessary code you need from the sourcecode released. This includes "Return to multiboot, standby, and other commonly needed things". |
If this is true, Lick, then what are the URLs for good examples of Free programs that implement these features?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#106629 - Lick - Sat Oct 21, 2006 6:03 pm
Well, returning to "multiboot" (I think he means the Supercard menu) is simply executing a resetting NDS-file released by the Supercard team. So simply any program (DSO? Moonshell? DSFTP?) that executes other files will suffice.
Standby mode, Moonshell. And generally, all the instructions are documented at GBATek (No$ version) and NDSTech.
_________________
http://licklick.wordpress.com
#106653 - tepples - Sun Oct 22, 2006 3:12 am
| Lick wrote: |
| Well, returning to "multiboot" (I think he means the Supercard menu) is simply executing a resetting NDS-file released by the Supercard team. |
Where is the collection of such resetting NDS-files for each make and model of memory card?
| Quote: |
| Standby mode, Moonshell. |
When using a large program as an example of a specific technique, it becomes difficult to find a needle in a haystack, especially when all the code comments are in Japanese.
| Quote: |
| And generally, all the instructions are documented at GBATek (No$ version) and NDSTech. |
Which sometimes does not provide enough context for a novice developer to understand what is going on or how to troubleshoot when the novice skips a step or performs a step incorrectly.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#106674 - Lick - Sun Oct 22, 2006 1:04 pm
To be honest, homebrew is indeed hard for the novice developer. That's why there is PALib and help on the 'net. If you can't parse a few source releases on your own, then I think it's wise to learn that ability first. (The code is in English. I didn't need the Japanese comments at all.)
Cross-brand FAT-ing is still confusing and screwed up, even for hardcore developers. So who's gonna write that holy plug-in? Will that plug-in be possible to write at all?
_________________
http://licklick.wordpress.com
#106687 - tepples - Sun Oct 22, 2006 6:58 pm
| Lick wrote: |
| Cross-brand FAT-ing is still confusing and screwed up, even for hardcore developers. So who's gonna write that holy plug-in? Will that plug-in be possible to write at all? |
That's wintermute's job. Once devkitARM R20 is out, we'll be able to use chishm's newer FAT library that has more device support.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#106693 - Darkflame - Sun Oct 22, 2006 7:39 pm
| tepples wrote: |
| Lick wrote: | | The scene is small enough to find all the necessary code you need from the sourcecode released. This includes "Return to multiboot, standby, and other commonly needed things". |
If this is true, Lick, then what are the URLs for good examples of Free programs that implement these features? |
Exactly, if its so easy, why do many homebrew progs still not have these basic features?
Hardly anything at all has a return-to-multiboot function.
If there was a simple site with basic examples, I think you would see these functions become near universaly adopted.
The whole idea of "if you cant do it, you shouldnt bother" is a horrible one, and really harming the homebrew community, imo.
Everyone can do everything, given enough time. But most dont have that time to spend...and if they did, they would rather spend it doing more interesting bits of code.
Simply having a code-based of stuff means people can spend less time on basic functions, and more time on the "fun stuff".
Whether its working it out on your own, or searching though huge bits of open source code to find the relivent bits...its all time.
A site with a simple list of common codes would be usefull to start with.
Allthough, a site allowing anyone to submit ds relivent code, and to catagorise it would be better no?
I think with lots of functions, improvements would be made, untill you have the "best version" of a particular function. (most stable/smallest/fastest).
| Quote: |
Which sometimes does not provide enough context for a novice developer to understand what is going on or how to troubleshoot when the novice skips a step or performs a step incorrectly. |
Heck, all Id want is a program that goes:
"Hello"
(standby)
"Welcome back"
Or something. Minimalistic code is best for demostrations, imo.
_________________
Darkflames Reviews --
Make your own at;
Rateoholic:Reviews for anything, by anyone.
#107330 - jester - Sat Oct 28, 2006 5:13 pm
well i think many cdoers should collaborate and create a awesome App for the DS thats on the grounds of Moonshell, DSOrganize, Beup, AIM DS, NDSMail, VGMDS and many more.
_________________
If anyone needs a dragonball online email me @ aaronthejester@hotmail.com