I've been looking in to Nintendo DS development on behalf of my agency and begun using the devkitPro/libnds and PAlib, it seems ideal for our needs until we decide if it's a viable route for us and hopefully invest/apply for a development kit and licence.
My main concern is that, while developing and learning PAlib style is it possible to eventually take a project built in this fashion and have it licensed and published? I don't really want to invest a lot of time learning this to have to learn a completely different setup. Essentially I suppose is PAlib just for Homebrew? What do I need to learn for Retail development of DS games?
Many thanks,
Anton
No, PAlib based projects cannot be licensed and published. See also http://wiki.devkitpro.org/index.php/PAlib
Don't waste your time learning or using PAlib.
Unfortunately even just using properly supported homebrew libraries you'll still have a fair bit of work to do moving to commercial development.
To do retail development (i.e. to get paid for your product), you'll need to get a real dev kit from Nintendo. The homebrew dev kits do not necessarily work in the same way as the real one, and (most importantly) they don't have access to the real dev kit's libraries.
Thus, if you develop against the homebrew dev kit, you're going to have to learn an entirely new library (which probably works very differently) when you move to the real thing.
Now, that's not to say that the homebrew dev kits can't be useful - they are a way to get code running on a real DS. As long as everyone realizes that it's a throwaway prototype, perhaps that could be enough to convince someone to spring for a real dev kit. If you go this route, you'll at least have something of a spec (it should work like the prototype!).
I also would advise not mentioning to Nintendo that you did this. I'm not in the industry, but they are obviously antagonistic toward the homebrew scene - I'm unclear how they'll feel about developers who started out on homebrew.
Related
Say we have a SystemC model of decade counter and I want to verify SystemVerilog Counter RTL using SystemC model. How can we connect these two in SV/UVM based testbench so as to communicate between them.
Mentor developed a free package called UVMConnect that was developed specifically for the application you are asking about. See https://verificationacademy.com/topics/verification-methodology/uvm-connect. You will need a simulator that supports SystemVerilog and SystemC simulating together, like Questa.
If you're using QuestaSim I think UVM-connect from Mentor is the way to go. When I first used it(4 years ago) it was very buggy and gave the most cryptic segfault errors I've ever seen. But, with help from the Mentor support I managed to overcome them and get stuff done. It should be more stable now, but if you have problems with it don't hesitate to contact Mentor support. They are very responsive.
However, if you're using Cadence tools and/or the e language I think that UVM-ML from Cadence is a much more comprehensive solution. It allows you to connect components written in any combination of languages(SV-SC, SV-e, SC-e) and it has nicer documentation and examples. I understand it's also compatible with all simulators now. You can find it here : http://forums.accellera.org/files/file/65-uvm-ml-open-architecture/
Not sure what Synopsis folks recommend for their tool suite. Maybe someone who used them can offer more information on this. But I'm guessing that both UVM-ML and UVM-Connect could work since their makers claim that they are portable.
And lastly, if you're planning to use SystemC as a verification language(very unlikely but just for the sake of diversity) there is something called UVM-SystemC which is basically a clone of SV-UVM written in C++/SystemC. It's currently in its alpha release and it lacks many features(register modeling, constrained randomization, coverage collection, etc.). It feels a lot like SV-UVM and I think it's a nice toy to play with in your spare time if you can't afford a commercial simulator license. You can find it here http://accellera.org/images/downloads/drafts-review/uvm-systemc-1.0-alpha1.tar.gz
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I'm looking to teach my kids programming, and it looks like I've narrowed it to two options:
jMonkeyEngine 3 (jME 3)
Unity 4.3
I couldn't find any "current" comparisons, and so I thought I'd ask:
Which is better jME3+ or Unity4.3+ for Teaching Programming vs Engine Benefits?
I'm not a game developer, but as a corporate & control systems developer I have experience in both C# and Java.
I'm currently leaning towards Unity4.3+ because:
From a Programming perspective, I think C# is a little cleaner than Java, though this means little if the Engine Coding & Object model encourage poor programming
Engine Benefits: Unity4.3+ will "supposedly" have upcoming support for both XBox One & PS4
Note: in fairness to jME, I will make note of this "pre-alpha state" iOS option for jME which is better than a marketing "supposed" perhaps: (http://hub.jmonkeyengine.org/wiki/doku.php/jme3:ios)
If they are equal in all other regards, which one has better Service integration?
Glad that you interesting in JME3.
I’m also working for a project that target making education programs (youngs and adults) in gaming enviroment.
If you going to let your children learn programming via game developing, it’s a good idea. But both JME3 and Unity are far more complicated to start with ( I assume your children are still young )… There are also few projects suitable for children to learn programming visually.
Greenfoot ww.java.com/en/java_in_action/alice.jsp
Alice ww.greenfoot.org/door
Kojo ww.kogics.net/sf:kojo
Those things (languages come with IDEs) have short learning curve and easy to get with, require minimum knowledge and suitable for children and starter. That’s the education side.
For the engine side. [This is my personal opinion]
I prefered JME.
I’m also left Unity ( did about 4-5 commercial games in unity my self) to go to JME. Before Unity, i also worked in Ogre, UDK, Torque and a lot other engines ( 10 more). I also worked with commercial engine in daytime job in C++, which code dirty as hell but run extremely smooth and cost millions dollar.
The reason is: Those engine tied you up with its limitation and pre-made sollutions. Of course that’s also half of the reason why you choose and engine at first. But when you hit that limitation, for example the license fee or the closed technologies. You will hate them as much as i did.
So that’s why i come to JME in a search of “complete” game developing and entertaining technology.
If you are an experienced Java and C#, in association with JME and Unity developer, i will name you a few things that can be *strong text*compared between the two:
License : free open source vs free / commercial
IDEs : Netbean – an open and extensible platform ( leading quality) vs MonoEdit (the most buggy IDE you can find on earth)
** The based technolgy:**
Graphics: OpenGL v2+ vs Modified renderer ( openGL compatiable v3+) Unity win in this one i suppose :( . It’s sad for a long term java developer like me seeing this. But we can improve the graphics from time to time i hope.
Data management: You choose ( H2, HyperTable, Neo4j …from Java world 100+ of those) VS Unity database
Data oganization: You choose (ES, OO, COD, data driven …) VS ES and data driven only.
Networks: You choose ( Java rocks in this one) VS Unity network ( high performance but never… ever defeat Java)
Cloud and distributed: You choose (Storm, Hadoop..) VS home grown "cloud techs”
Note that i still usually using Unity and JME3 at the same time, for my job and for my hobby. I used Unity 4 with fancy mecanim animation, sub stance material … at day, and using JME3 for research and improve it at night. IMO, JME3 is the game engine which worth to learn, and it will rocks and shine in the future!!!
Hope this help!
It's hard to make a comparison when I have never actually used Unity. I have seen demo's and it's interface however. But having used the jMonkeyengine for about 2 and a half years, I can say I am a happy customer :).
Unity probably has a bit more of everything: developers, users, bells and whistles, but there is a cost associated to that.
Similarities between the 2:
- Big communities (Unity is bigger)
- Many free tutorials
- Rapid development (here's a link to a couple ludum dares I've been involved with using jME http://www.ludumdare.com/compo/ludum-dare-28/comment-page-3/?action=preview&uid=16152, http://www.ludumdare.com/compo/ludum-dare-24/comment-page-1/?action=preview&uid=16152)
- Easy to distribute to Windows/Mac/Linux/Android
The jMonkeyEngine is completely free and all open source (New BSD License). So you can see all the inner workings of the engine, and even change it if you do not like something (of course you are welcome to commit the changes back :)). So you will learn a lot more by delving into the jME source code.
C# and Java is a debate that can go on for ages, but I don't think it should be a defining factor, they are very similar in nature. There doesn't exist a usable iOS version in jME, and I don't think there is any immediate plans for Xbox One and PS4, so Unity will win there.
JME is a bit more hardcore engine than Unity.
JME:
- strong community (english language mostly)
- OpenSource and free to use.
- has many cool tools. But Unity has much more i guess.
- Simple to compile and code with all platforms.
- Supports Linux. You can develop games in Linux OS.
Unity:
- Strong community (with many local communities and languages)
- Non free. But it has professional tools.
- Has javascript support. You can add scripts inside of the editor.
- Has really cool world editor. But coding is better in JME SDK.
I use JME. But it's hardcore in many cases.
It really depends on what you aim for.
The pro on unity is especially way to get assets into the engine (via the shop).
With jme3 you need to be able to at least partly work with blender/3dsmax or similar. Or use a graphic style where it does not matter (eg 2d or blockworld)
Also it has better state of the art features in terms of lighting and shadowing.
But you kinda need to pro license sooner or later, as even basic stuff as lod is tied to it
http://unity3d.com/unity/licenses and it is not that cheap.
The pro with jme3 is that it does not limit you. It is only a core engine but also not tailored for some use-cases.
As far as I understand Unity uses a kinda Entity-component system but without separate systems. (The components contain the logic)
In jme3 you are free to use whatever you want, and are encouraged to make a clean split between logic and graphic. You are free to use whatever programming type you prefer (eg ES,OO) As jme is jvm based you also have access to other jvm languages, eg for functional programming via scala.
So it depends on what your target(and budget) is, more about developing and their specifics, or more about making a own game.
Regarding the version controll,
JME3 works fine with git and svn and kind everything else. As there are no special files or logic tied to any of them.
I can't say I've ever used Unity but here are some things I love about JME3:
Completely free & open-source under BSD license
Awesome SDK based on awesome NetBeans
Deployment to Linux, Mac & Android (as well as windows) with 1 click, I have no idea if Unity can do this
Amazing active community, constantly creating new plugins and features (IOS deployment coming soon, possibly), they will also help you with any trouble you run into
Networking is awesome
Can use other Java libraries or features alongside
As far as features of the engine go, Unity probably has more. However, I highly recommend JME, it is a great engine. Somebody else said you need knowledge of blender, whereas with Unity they have an asset shop. While Blender knowledge is (very) useful, there are hundreds of websites online that sell or give away for free assets (for instance www.turbosquid.com).
I have to ask, is whomever you're teaching actually ready to program for a game engine?
If the first thing that has to be taught is a hello world script followed by learning what variables are, then both options do nothing but over-complicate what needs to be a simple learning environment.
Even if they have the basics of programming down, they should know what the basics of game programming are. They should know what a vector is and how matrix math works with some underlying understanding of how an engine operates.
I don't know about jME, but with Unity, this would be the point where they could actually write code that does something in which they can earnestly say they understand why (which should be the most important part of teaching someone). I describe Unity as the simplest, big boy toy out there. That still means they have to be ready for the big boy toys in the first place.
Oh, and stick with the free version of Unity. Most pro features are graphical elements like bloom lighting that don't effect a programmer's capabilities.
I just wonder. Is there anybody in the world, using TDD or BDD to write an OS? And is this even posible? I've tried to google it, but didn't find any kind of information.
So, guys. Is it possible to build an entire OS using TDD? And BDD?
It is possible to use TDD for most of OS development and for most of the code. It may get tricky at certain times/places due to limited testability of low-level, especially CPU/hardware-specific, code. These parts either may receive less direct test coverage (if that's OK) or can be tested in virtual machines or CPU/PC simulators.
It is definitely possible. I don't know anyone who is doing it.
As a proof point, I would point out what people are doing with test driven infrastructure with Chef and unit and behavioral testing there. For more info, see TestKitchen for Chef.
I'm getting into game development right now, and I want to do 3D games. I have been checking out UDK, Unity, and CryEngine 3 SDK. All of them, I can see, have their pros and cons. Unity, however, I am starting to rule out because I'm wanting to do Game Development as a job in the future. Since the Unreal Engine (which, as I understand, is 99% the same as UDK) and CryEngine 3 are the industry standards, apart from GameBryo etc.. (which I don't have money to buy as I'm 16 haha)
From what I understand the pros of UDK are:
Simpler (In terms of Scripting)
Runs on more computers than CE3
Industry standard, used in MANY top-notch games.
Kismet is really nice (for level-wide editing)
Development for iOS is possible, and free (minus the $99 fee to become an "Apple Developer"
Cross Platform (PC, Mac, iOS) for the UDK. UE3 (as I understand) is PC, Mac, iOS, PS3, Xbox360, and Android?
$99 to sell games, first $50,000 in sales is royalty-free
The cons are:
Must exit the editor to recompile the code every time you change the UnrealScript code.
Worse workflow than CryEngine 3
Soon to be replaced by Unreal Engine 4
Crashes often.
Not many tutorials.
The pros of CE3 is:
AMAZING Terrain Generator
True next-gen-top-notch graphics
Best water ever seen
Much better workflow than UE3
Rarely Crashes
The Cons are:
Must log in to use, if you lose Internet connection while editing, you won't even be able to save.
Expensive if you want to make commercial games.
Doesn't run on as many computers
Only on PC, PS3, and X360
More complicated scripting?
Is what I said the basis? Are there any pros or cons I have missed? Which do you recommend for a beginner (to game development, not programming in general. I am well versed in Python, know VB.NET, C#, HTML, and CSS) Is Unity a possibility for a game-development company to see potential in you?
EDIT: P.S. I thought I should mention this... I do not plan on making FPS as my main genre. I know it will be hard to do anything else with either UDK or CryEngine, but I don't mind. I need the learning experience. Mainly, can UDK AND CryEngine do this? I KNOW UDK can, but I'm only about 50% sure CryEngine can, I haven't seen many people ask this.
I'm learning UDK at the moment. Click on the welcome screen to access online video tutorials. This Buzz3D dude makes the best tutes ever. Although he uses an older version of UDK, I'm able to keep up and I've learned heaps. UDK is a very exciting editor. I plan on checking out CE3 at some stage. Dunno much about Unity. Might be good for developing to the upcoming ouya console (which is a bit of a dark horse for the industry).
I have played a little bit with UDK before and I think the pros and cons you mentioned are valid.
I don't know anything about the internal workings of game company recruitment, but I think for a beginner Unity3D is a choice worthy considering. Unity is not as powerful/productive/market-standard as UDK, but it does have some advantages:
C# scripting
Comprehensible documentation, tutorials and active community
Friendly and easy-to-use IDE, Script Editor and (most importantly) Debugging Tools.
Anyway, if you follow some tutorials it shouldn't take more than a few days to learn the basics of Unity and make some game prototypes. I would recommend it as a staring point even if you are going to migrate to another engine later.
Just on the pricing of each, Read the notea correction to UDK pricing.
Here is the cost of each currently
Crytek: For Indy Developers
-"Crytek require only 20% of the developer’s revenues from the commercial launch of their game." -I find this more appealing for sheer simplicity's sake
UDK:
-"US $99 up-front, and a 0% royalty on you or your company's first US$50,000 in UDK related revenue from all your UDK based games or commercial applications, and a 25% royalty on UDK related revenue from all your UDK based games or commercial applications above US$50,000*"
*Note there is this to,
-"If you are using UDK internally within your business and the application created using UDK is not distributed to a third party (i.e., someone who is not your employee or subcontractor), you are required to pay Epic an annual license fee of US$2,500 per installed UDK developer seat per year. This license fee only applies to UDK seats used for development; no license fee is required for hardware where only the resulting applications are installed."
Alright I am not the best but what this seems to be is if you are a small dev team you could get away with only one charge of 2,500 by listing every one under on "employer" but I am not even sure If it applies to indie devs.
LINKS:
Cryengine: http://mycryengine.com/index.php?conid=43
UDK: http://www.udk.com/licensing
Thanks for you post,
Robert
I don't see where you get the idea UDK crashes often and "doesn't have many tutorials"?
You can also get away with having to recompile each script change with a system called "archetypes", I won't explain in detail, but you get the gist.
if you try to get anything outside of CE3 other than an FPS, you're going to have to dig into their C++ code which I can tell you now is the least documented, least commented, code to date.
I'm interested in creating a basic web application (for learning, but I want to finish within a few months), and I've read that using a web framework can make that task much easier.
After reading about different frameworks online, it seems to me that using frameworks would hide a lot of detail on they work. I fear that if I use a framework, I won't really know how my website is running.
Is it important to understand how frameworks do what they do, or am I worrying too much? (eg. I don't know how the Linux kernel works, or the C compiler, etc.)
Even if you don't have a particular interest in web frameworks, I would say it's good to play with a few and then crack them open if only for the exposure to new design patterns and solutions that can be applied anywhere in development. (MVC in particular when talking about most web frameworks)
It is (to some extent) important to understand how frameworks work, but you'll never learn that without using them.
So, start using some framework and you'll get basic understanding of it. And then, if you have interest, you can always dig deeper into it (maybe even submit patches and participate in its development). But not in the opposite order.
Using your analogy, you don't become Linux kernel developer without being Linux user for some time.