Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 20 Dec 2007
Offline Last Active Mar 20 2014 04:42 PM

#5117732 Monogame Resources

Posted by Ultrahead on 17 December 2013 - 09:05 PM



Please also check The APE ...

#5117298 The APE on IndieGoGo

Posted by Ultrahead on 16 December 2013 - 05:55 AM

As part of a content-pipeline tool I'm developing called the APE, I've also developed a command-line app called APEBuild:




You can get more info about it here: http://amapplease.blogspot.com/2013/12/the-asset-pipeline-editor-part-5.html


Also, check this thread for more details: http://www.gamedev.net/topic/651102-upcoming-tool-the-asset-pipeline-editor/



#5116733 Upcoming Tool: The Asset Pipeline Editor

Posted by Ultrahead on 13 December 2013 - 12:58 PM

As promissed,the post is here: http://amapplease.blogspot.com/2013/12/the-asset-pipeline-editor-part-5.html

#5116493 Upcoming Tool: The Asset Pipeline Editor

Posted by Ultrahead on 12 December 2013 - 09:52 AM

Hey, great questions.


They deserve a proper explanation on my blog but I'll answer them briefly here:


1. "APEBuild": yes. In fact, when I designed the APE i thought of this use case; this feature was a corolary of the way I designed the tool in order to test import/write units before promoting them to the editor. As a matter of fact, project files contain all needed info to build assets. So, when you call the APEBuild you eiither indicate whether to build the whole solution or specific projects.


2. Repository: in the way the APE works there is no need to watch files, since compilation/build actions in the editor need user interaction (press a button, etc.) and it handles raw files as opposed to source files. Let me explain it a bit better: when you add a file, the editor copies the source file to the solution's repository and add a raw file in the solution tree. Thus, as long as you change the source file in the repository, next time you build assets this updated source file will be loaded, processed, and so on so forth to obtain the asset file. So, if you have say a mono sound.wav file on the repostirory and then you manually replace it with a stereo sound.wav file, the later kicks in for next builds. 


3. Processing: the APE will not replace production tools like Photoshop, Sound Forge, and so on so forth. So you will need to create your source files there: jpegs, wavs, mov, etc. What the APE provides is a way for you to indicate how to convert them to the file format you need for your games. In case the built-in import/write units or the ones provided later on by me and or any other user are not useful to you, then you can implement your own with full control over them. So, if you want to implement a processor that converts WAVs into OGGs, you can go ahead and do it with ease. What about resizing a texture? Sure. What else? Everything you can imagine of that can be achieved by setting parameters on a property grid. For example, for the case of XNA'ers, in part 4 of the series I show a processor with many features that pre-multiply alpha, resize textures, changed formats and so on. To sum up, to create source files use production tools, to convert them to game assets, use the APE.


Thanks for your smart questions. Hope you like the answers. More in my blog soon ...

#5116390 Random Development Tools

Posted by Ultrahead on 11 December 2013 - 09:08 PM

The one I'm developing: the Asset Pipeline Editor.




Spine is great for skeleton-based 2D sprites. Tiled is also great. For audio, I use Audacity. For video editing, Magix's products. For 3D modelling, Silo3D (but it's no longer developed I guess). Daz Studio is good for skeleton-based 3D animations.

#5116387 Upcoming Tool: The Asset Pipeline Editor

Posted by Ultrahead on 11 December 2013 - 08:49 PM



During this year 2013 I've been developed a tool named "The Asset Pipeline Editor" (or "The APE") which allows game devs to build their own content pipeline, if needed, as well as managed asset files for their games on a per-platform basis. Here is an example picture of it:




The tool is being use for inhouse projects right now, so it's a work-in-progress for public release. In a few weeks I will starting an IndieGoGo campaign to bring this baby to its first release/major version.


It's important that even though I'm using this tool for XNA/Monogame-based projects right now, it can be use with any custom game engine that does not have a CP of its-own regardless the langauge being used: C++, Objective-C, C#, Java, Phyton, etc. So this is not for games being developed with Unity, UDK and such.


If you want to see a short trailer, please follow this link: http://www.youtube.com/watch?v=Vjx0UGebnZ0


Also, on my blog you will find a series of posts with more in-depth details about it (four, so far):









And you can always follow me on twitter for latest news: @Yoruguaman


Hope you guys like and support it.



#5038032 Should I use XNA?

Posted by Ultrahead on 01 March 2013 - 09:01 AM

The Monogame Team is afaik developing a Content Pipeline, however they are integrating it to the C# project as XNA did (that is, to VS or Monodevelop) which I believe is a mistake. The content pipeline component imho should be developed independently from any IDE, as the Wave Engine guys did, so that it remains unaffected from changes in the versions of the IDEs.

#4984697 Is XNA dying and MS forcing to C++?

Posted by Ultrahead on 28 September 2012 - 06:06 AM

I´m Staying at SharpDX Posted Image

Wise decision ... :)

#4982133 Is XNA dying and MS forcing to C++?

Posted by Ultrahead on 20 September 2012 - 01:19 PM

If you think of it, Monogame is becoming the successor of XNA for new tech (ANX is another option, too). Say that you concentrate only on Monogame abandoning XNA completely, the only platforms you lose are WP7 and Xbox360. The former is being replaced by Win8 and the XBLIG channel never succeeded. So with Monogame you've got XNA-like code that supports (and will support) Windows (including Win8 for ARM), WP8, NaCl, and many OpenGL-based platforms. Once Monogame imlements its own code for the content pipeline, you can say goodbye to XNA. The only doubt is related to the XBox720, but if it eventually allows C++ for indies then Monogame would also support this platform.

And for those who want a lower-level access to the DX APIs themselves with C#, you can use SharpDX.

#4981737 Is XNA dying and MS forcing to C++?

Posted by Ultrahead on 19 September 2012 - 10:34 AM

There's a great deal of novelty around C++11 even inside MSFT. Plus XNA was never updated to support DX11 (even though it was ported to WP7 through DX10.1). This is the reason why C++ is strongly recommended these days by MSFT.

For what I can uderstand from what I see/read, XNA will still be there but tehre will be no more updates nor support to it. So, you will be still able to use it for the creation of games for supported platforms (including Win8 Desktop and WP8). Now, if you still want to use XNA-like coding, then you could then use Monogame or ANX (both offering support for Win8 on ARM and WP8, through SharpDX).

Now, if you prefer to directly use DirectX APIs but want to stick with C#, then my suggestion is SharpDX (I'm not sure whether SlimDX is been developed any longer), which is a 1-to-1 wrapper of DX, supporting versions 11.1, 11, 10.1 and 9c.