Since I’m not working actively on RICcreator in the moment, not much have happened the last few months, however I just rewrote some terrible code which was not safe. RICcreator would crash if the settings.xml file is formed differently than expected, so when a new version changed the format, it would crash if the old .xml file was kept.
XML handling
The XML parser previously used was rapidXML which promises great performance, and since I want to do some game related programming with XML I wanted to learn the API. However as I tried to use it with RICcreator I quickly realized it was rather tedious to work with. So I slacked on the implementation. Most importantly, I didn’t do any validation and simply chained the node lookups. So for example to get to the “settings” node in the “RICcreator” node I did this:
doc.first_node( "RICCreator" )->first_node( "settings" )
However if first_node() can’t find the node it returns NULL and in case of this the second call will try to dereference a NULL pointer and crash the application. To avoid this it should have been done like this:
xml_node<>* root = doc.first_node( "RICcreator" );
if( root ){
xml_node<>* settings = root->first_node( "settings" );
if( settings ){
//Process it here
}
}
This is quite some code for a simple lookup, so as said I slacked. Adding nodes to a new document (when saving the settings) was even more tedious as you had to allocate nodes and then add them. (On the other hand, I couldn’t slack here.)
So I have been looking for a simpler C++ XML parser and recently I heard about pugixml. I like the API much better, it is also a lightweight parser and apparently even faster than rapidXML so I tried it out. The previous lookup would look like this in pugixml:
doc.child( "RICCreator" ).child( "settings" )
This doesn’t share the problem rapidXML has, because child() returns a “NULL” object on failure. The NULL objects functions all return another NULL object, so you can chaining like this is completely safe as long as you check the final result.
So I have rewritten all XML handling to use pugixml now and I’m quite happy with the result. The code is a lot prettier and most importantly, it shouldn’t be able to crash like before.
Other changes
The dithering have been changed to use Filter Lite instead of Floyd-Steinberg, which produces nearly as good result but which is quite simpler (and therefore faster).
A fun addition is grayscale importing support. If you want to toy around with grayscale images on your NXT, RICcreator makes this easy by letting you import the same image several times with different thresholds in one step.
The Number opcode is now no longer aligned to multiples of 8, as this limitation has been removed in the enhanced firmware.
A few bugs have been fixed and it should be possible to compile in Visual Studio again. (I haven’t checked after rewriting the XML stuff though.)
Download
Revision 165 win32: RICcreator rev. 165 – win32.zip
Revision 165 source: RICcreator rev. 165 – src.zip
August 8th, 2014 20:23
Seeing as this is the most recent post about RICcreator, I thought I might type up my thoughts on it so far.
So far I’ve certainly liked it, been able to edit a couple files already to my liking, though I think there’s a couple minor things that could be improved:
(picture for reference)
http://i.imgur.com/ODxF4Kx.png
A and B both show places where the layout or window overlaps content, and you can’t resize these elements. B’s case is not that major at all though, unless there’s more text. Also, the version number seems wrong or unused :P
A, on the other hand, blocks all but a single column of pixels of the ▼ and ▲ buttons for the Values section. I can still highlight the box and type values manually just fine, but that section just looks very cramped. :/
Now for a couple suggestions! (Ironically these are mostly stuff from nxtRICedit)
regarding the grid overlay, imo it would be nice to be able to disable it, and maybe be able to change the dimensions of the blue boxes? (for example 8×8 woulda been handy earlier today)… but for sure the numbers at the sides telling what each blue mark is would certainly help with the VarMaps…
regarding the copy + paste, i was able to figure it out after a few minutes of toying with it, but actually having some documentation would help with this hehe, like double-clicking to stamp/paste and needing to switch to a different tool then back again to copy a new thing :P
another feature i liked in nxtRICedit was the ability to shift all selected rows or columns, handy for removing whitespace quickly, and the mirror button was nice for sprites like dear Mario up there.
Having tooltips for the bottom three (or maybe all) of the Actions buttons would be pretty nice, since i wouldn’t know what they do without using them with the exception of copy and paste.
Also something I noticed is CopyBits and VarMaps having “unsupported” fields in their expanded tree nodes, I have no idea if NXT doesn’t support it or just RICcreator, or what it’s even supposed to be for, heh :P
So, that’s all the improvements I could possibly think of at the moment, but like I said earlier it certainly works as it is without any problems. Please don’t feel obligated to make any of these changes or additions. :P
I rate it 8/10, on par with nxtRICedit.
-2Tie, formerly monkyman95.
August 8th, 2014 22:31
Thanks for the feedback, I really appreciate it. I have added several of your suggestions in the issue tracker, in case I feel like doing something on RICcreator again: https://github.com/spillerrec/RICcreator/issues
But this was why I thought it was important to have an open-source RIC editor; even if the main author loses interest, other can still make bug-fixes if worst comes to worst.
Funny about the “about” box, I never noticed it. I guess Win8 uses a larger font…
I was never really satisfied with the Values section, as I wanted it to be small, but I couldn’t find a good way of doing it. (I have just been using the scroll wheel myself, instead of the buttons.)
Changing the grid size was planned, but I never made the settings window I intended to place the option in… Did also consider the ruler, but felt it was too much work.
About the shifting feature, do you use it for anything else than removing whitespace? I found it rather strange, and therefore just have the auto-crop action (last button in the action section).
The “unsupported” stuff is just that it can’t display the collection of x,y,width,height values in the box. I wonder why I haven’t added that yet…
August 9th, 2014 05:24
alright, all sounds good.
Ehh, I wasn’t using the shift to crop the outside space, but rather, i’d make my spritesheet originally with a 1px border around each for visibility as I work on them, then when they’re done i’d select, say, all of the sprites but the leftmost row (including that padding), and tap the shift to “bump” the rest to the left one, removing the padding. I’m not sure how many other people make spritesheets on RIC like this (or at all for that matter), so while my first idea was to request a button to autodetect all rows or columns that are all-white and effectively remove them, optimizing space in a simple way, i don’t see it as something very many people would use, heh. I’m currently fine with just copying and pasting the sprites over one, does the same thing but with like three more clicks :P
-2Tie