I'm interested in experimenting with 9Patch bitmaps. There's a ton of guides on how to make the PNGs (which is very easy) but not much on how to actually code the 9.PNGs into your code (other than the occasional forum post).
Is there any advantage to using NinePatchDrawable over Cocos2D's CCScale9Sprite? NinePatchDrawable's look quite complicated!
Related
Apologies for asking such an open-ended question, but I want to emulate some synthetic assembly (not for a real processor) in C++ and I want to decouple the assembly from the implementation of the simulator it runs on.
Writing a DSL or similar seems like the obvious way and I have some experience of this, having done something like it (actually a mixture between a DSL and an interpreter) in Groovy.
boost::proto seems like the obvious choice, but I find the documentation utterly impenetrable, even though, as I say, I have some grasp of the basics.
Is there any alternative tutorial or similar out there that explains - in a way that focuses on the practicalities of writing a DSL rather than the theory of ASTs etc - how to do this. Or is there an alternative? Right now I am stuck with implementing the assembly instructions as methods of classes that make up the simulator, which makes them very tightly bound and extremely difficult to maintain the code base.
I second the comments suggesting that you may have a badly matched XY-problem here.
Meanwhile, the best introduction to applied Boost Proto for an embedded eDSL was on Dave Abrahams' cpp-next.com blog. Sadly, that has gone off the air.
Eric Niebler, author of Boost Proto, has offerred to send people the raw dumps of those pages, on request:
The C++ community is suffering from the loss of the cpp-next.com website and all the great content that was once hosted there. In the past 2 months, I’ve gotten many questions both about the site and about the fate of my “Expressive C++” article series. In response, I will re-post my old articles on this blog. But I’m busy and it’ll take time. In the meanwhile, if you have a desperate need for a readable introduction to Boost.Proto and domain-specific embedded languages in C++, and you don’t mind reading raw markdown, email me. I’ll send you what I have.
http://ericniebler.com/2014/05/24/cpp-next-com-and-the-expressive-cxx-series-2/
In the mean time, waybackmachine has some of it, e.g.:
http://web.archive.org/web/20120906070131/http://cpp-next.com/archive/2011/01/expressive-c-expression-optimization/
http://web.archive.org/web/20120315111227/http://cpp-next.com/archive/2010/10/expressive-c-expression-extension-part-one/
http://web.archive.org/web/20120430163700/http://cpp-next.com/archive/2010/10/expressive-c-expression-extension-part-two/
*
Looking for a GUI framework to use with C++ to "modernize" an existing interface for touchscreen.
I'm a novice programmer with a background in C++/Java that was just assigned a project that involves taking an existing C++ program using MFC (3 data views, multiple text/radio controlled dialog boxes, etc.) and redesigning the interface to be "touch-screen friendly" such as larger button controls, sliders and whatnot.
I've been given pretty free-reign with instructions to make a "more modern looking interface" as opposed to the typical bare-bones MFC I've been given. I know I have quite a bit to learn either way, so any suggestions are helpful.
So far the options I've come up with are:
MFC just tweak existing controls to accommodate touch input, keep crappy looking interface.
Managed C++ or C++/CLI figure out how to keep the underlying C++ structure while being able to design a new interface with WPF or Windows Forms.
Qt completely new to me, but seems a promising alternative.
Really I just need to find a way to make this program look like it wasn't written over 10 years ago, and so far in teaching myself MFC, it doesn't seem that flexible in terms of incorporating any sort of graphic-design/themes.
Are there other alternatives I should be looking into? Is there more to MFC than meets the eye and I just need to learn more about it? As I said, any suggestions of things to look into are helpful.
What you've listed as #1 could really be either of two approaches. One (call it 1a) is to continue using the same version of VC++ and MFC as the original, and do only the bare minimum of editing to increase the sizes of the controls where needed. Short of encountering some fairly bad luck in how the existing code is written, this might not involve any real programming at all, and would be relatively quick and easy.
The second (call it 1b) would be to do the update using the current version of VC++, MFC, etc. This would probably involve some code updates, but probably not anything terrible (though if it's much more than 10 years old, significant code updates could be needed as well). With some care, you may be able to update the UI quite a bit (e.g., change from menus to ribbons, include color theme support), still with fairly minimal investment.
Your #2 could easily end up as nearly a complete rewrite. Despite superficial similarities, C++/CLI is a completely different language from C++. The only way this really makes sense is if you have quite a bit of non-UI code you can leave alone completely, and use C++/CLI exclusively as a "bridge" between existing C++ and a .NET UI (and the UI is fairly minimal, so the rather mediocre tool support for C++/CLI doesn't cause a big problem). If your UI is any more than fairly trivial, C# has enough better tool support that it may easily be a better choice than C++/CLI.
Your #3 will probably require only marginally less rewriting than 2, at least of the code that's related to the UI. While the code would remain C++, Qt is quite a lot different from MFC. The big advantage would be if you (might soon) want to support something other than Windows (e.g., iOS or Android). For portability, Qt has a huge advantage over any of the alternatives you've named.
A lot comes back to a question of how much C++ code you can retain intact. If you have a lot of code in an "engine" that's cleanly separated from the UI, and a fairly simple UI, then retaining that existing code make a lot of sense, and rewriting the UI from the ground up isn't all that terrible of a problem. On the other hand, if the UI and business logic code are heavily intertwined (fairly common) then any more than really minor tweaks to the UI is likely to me significant rewriting of the rest of the code as well.
Conclusion: if the UI is heavily intertwined with other code, your only real choice is between 1a and 1b. If the UI is easily detached from other code, the choice between 2 and 3 is (at least to me) primarily one of whether portability is at all likely to matter (now or any time soon).
I'm wondering how good is the Boost Spirit Library.
I have begun to read the documentation, but it seems to be a very huge framework, and ask for a lot of time to be master. I really don't want to waste my time on a framework which is not so wonderful as it could be.
I would like to have some opinions on this framework from user who very well known it.
My opinion is surely biased, so please take it with a grain of salt.
Spirit is a huge framework allowing to create very fast parsers and generators with C++. The created parsers and generators integrate nicely with your own data structures. Spirit requires some understanding of its underpinnings to be used efficiently. The documentation is fairly readable and explains things in easy terms. There are literally hundreds of examples available, which I suggest to consider part of the documentation. Understanding those examples is integral part of learning how to use Spirit. Simple tasks are easy to solve, more complex tasks tend to require some thinking and experimentation to get right (but that's probably not specific to Spirit). Spirit has an active community, a responsive and helpful mailing list, and a cool website with tons of additional information. Generally, if you're stuck, it's straightforward to get help.
You pay for all this niceness with increased compile times and huge compiler template error messages if you make an error. But once it compiles it usually works on the spot.
Old question that I came across while searching for some information on Spirit, but I figured I'd put my 2 cents in here for future readers.
At first I was pretty well daunted by the learning curve of Spirit, to the point that I almost gave up. But I'm very glad I kept going. The performance of this parser is just sick. I was previously using PCRE to parse HTTP headers with some simple regular expressions. That's a fairly simple operation and PCRE is pretty fast, so I didn't expect to see much of an improvement - if any - in the speed.
Boy was I surprised to see that it increased the performance by over 2000%. With Spirit I can parse 100,000 sets of HTTP headers in a little more than 1/4th of a second.
And the kicker is the code is so clean and compact compared to the equivalent code with PCRE. My original function that was 80 lines of PCRE gobbledygoop is now a cute little 14-line Spirit grammar, and a Fusion adapter to push the outputs directly to my class structure.
Difficult to learn, and the build times can get pretty bad, but the payoff is fantastic.
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 5 years ago.
Improve this question
I'm looking for some answers for a project I'm thinking of. I've searched and from what I understand (correct me if I'm wrong) the only way the program I want to make will work is through 3D application. Let me explain.
I plan to make a studio production program but it's unique in the fact that I want to be able to make it fluid. Let me explain. Imagine Microsoft's Surface program where you're able to touch and drag pictures across the screen. Instead of pictures I want them to be sound samples (wavs,mp3,etc). Of course instead the input will be with the mouse but if I ever do finish the project I would totally add touch screen input compatibility! Anyway, I'm guessing there's "physics" to do with it which is why I'm thinking that even though it'll be a 2D application I'll need to code it in a 3D environment.
Assuming that I'm correct in how I want to approach my project, where can I start learning about 3D programming? I actually come from PHP programming which will make C++ easier for me to learn. But I don't even know where to start. If I'm not wrong OpenGL is the most up to date API as far as I know.
Anyway, please give me your insights guys. I could really use some guidance here since I could totally be wrong in everything that I wrote :)
I would like to add that I'm most likely looking for tutorials, Linux 3D programming sites, source/demos (google failed me for the most part).
Note: I also understand this is not a project I'll finish in weeks, months and might take years. That's fine, I want to get C++ under my belt however long it takes. I'm just looking for opinions, sources, tutorials and things that might help me (as stated above).
I don't know much about the MS Surface, but I'm a musician and multimedia artist working mostly with code, so... My advice is very much different - it doesn't matter if it's Irrlight, Orge, pure OpenGL or anything else. If you don't know much about 3D prgramming you'd better start with something different. There are several environments for artists to work with graphics, multimedia and code. Try one of them and watch the projects made in each of them on the project's websitees and on Vimeo. I think most of what you want to do is already done, but still can be very inspiring. The environments that come to my mind are:
Processing - great prototyping environment by Ben Fry and Casey Reas. I use it always before coding anything serious as it provides me with all the multimedia and communication libraries i need, it's simple like hell and it's Java so you can easli deploy your apps after all! (As far as I remember there is touch surface library for Processing)
openFramewoks - same as above but C++, but it's less clean and still under development. It's very easy to prototype in Processing and code finally in openFrameworks as the latter was very much influenced by the former. (The touch surface library is implemented for oF for sure)
NodeBox - great and very powerful environment in Python. Has a very strange but great and intuitive (after all) GUI with some very unique methodolody of work!!
SuperCollider is a wonderful sound processing and algorythimc composition programming language with a very easy to code GUI library and graphics API. It gives you everything you ever imagined about sound programming functionality.
Pure Data - graphical approach toward programming. Made by Miller Puckett (the co-author of Max/MSP) with OpenGL (GEM extension) functionality provided by the guys from IEM in Austria.
Final good advice: Books!!! Programming Interaction (O'Reilly), a few books on Processing website, classic work - Computer graphics for Java programmers (great one, really!!). Read as well all the chapters about domain languages and domain knowladge in "97 things every programmer should know". It can really help!!
BTW: if you don't concider heavy real-time procedures thing about Java (Java2D, Java3D, JOGL) - it's millions times easier then C++ and Processing is actually Java, so you have a very good prototyping environment that can produce ready to use Java classes and applets. I used Processing in real-time theatre productions where stage movement was controlling the sound (syths and hardware samplers) all made in Processing, so this "heavy real-tme" means HEAVY real-time!!
If any further questions about this particular domain programming - don't hesitate to email me.
Coming from PHP won't make C++ any easier to you as riding a bicycle won't make driving a car easier.
Now, I think for Linux, your only choice is OpenGL as an API, and use any of the many wrappers, 3D programming frameworks, and what not available.
Maybe you can go into an easier language, like Python, and if there are OpenGL bindings (which I am pretty sure there is) you can use that, that would make the learning curve more easy and fast.
Update:
Today I wouldn't recommand Ogre3D for a lot of reasons (including very poor long-term interface, which defeat the purpose of a dependency for long term usage - although it does have nice performance sinc v2.1).
There is currently a lot of other alternatives which work well on Linux.
Ogre, using OpenGL on Linux-based OSes, will save your life and time, compared to using OpenGL that is your sole alternative.
That said, to use Ogre, you'll have to know a fair amount of knowledge and practice in C++.
And you will have to know about "graphic pipeline".
You can use C with OpenGL, that seem simpler, but it make you loos time by not providing higher abstraction of the graphic pipeline as Ogre does.
And almost all graphic engines are written in C++ anyway.
Now, if you try to learn C++, take a good book like "Accelerated C++", take a deep and long breath and please forget all you learnt about php before. Be humble in your search for knowledge and you'll get it faster.
You'll be interested in:
OpenGL (obviously)
Box2D (a 2D physics engine)
SDL (a portable media library)
You can find basic tutorials for them on the web. However, think if you really want to code in C++. The language is very powerful, but not easy to learn, and really hard to master. Wouldn't it be better to use a rapid development language like Python with PyGame?
Don't get me wrong -- I love C++ and it's my language of choice, but unless you're working on top-notch performance, operating systems or compilers, it may be overkill to learn C++'s up and downsides the hard way.
You need neither 3D graphics or a physics engine for this. The UI could even be done in a browser using some funky javascript.
However, the audio engine for something like this is going to be a pretty complex, performance-oriented beast, and is probably best done in C++ (or maybe OpenCL).
Finally, are you sure you're not reinventing Pure Data?
I prefer Irrlicht as a lighter, easier-to-learn, but less feature-complete API than OGRE.
It's literally possible to write a prototype in a few minutes in Irrlicht, and the code itself is easier to understand.
The best thing about it is that it would interface seamlessly with Irrklang, a sound library that may help you with your project.
I know that the question has already been asked and answered, but it was more than one year ago and it looks like there are new alternatives out there.
So I'm coding a game with the SFML library (which I'm starting to find pretty much cool actually) and I'm looking for a light and fast event/delegate library.
After doing some research and having put aside the classical ones (Boosts.Signals, libsigc++), I found "cpp-events". It does not look very popular right now — since it is a very recent library — but it seems worst to be tested. I would be very interested to know if someone here tried it and can give a little feedback.
Do you have other similar (or better) options to suggest? I look rather real projects (which will be maintained) than answers on forums.
Thank you !
My feeling is that http://www.codeproject.com/KB/cpp/ImpossiblyFastCppDelegate.aspx is a great implementation for games. No dynamic memory allocation, reasonable performance, simple to debug => great for games.
I have used similar delegates in the past, this implementation looks more efficient.
The one you suggested mentions thread safety, but I would not be comfortable with a delegate based interface being used between threads. That may work fine on a small project but if a team grows, so too does the potential for disaster. I would also question the performance implications of such a feature.
Also take a look at Boost.Signals2 which is the thread-safe version of Boost.Signals. I'm using it at work in a medium-sized project and I'm quite happy with it.