I did, yeah. You just keep adding complexities--now I need to embed a palette within the image! I'll have to think over how I want to handle that.

Link for when I need to find it: http://www.cemetech.net/forum/viewtopic.php?p=218819#218819
Yeah my bad, sorry about that!

Its 32 bytes and then each pixel is an index to this palette. Note that my conversion tool (which is a hacked job) just takes the first 32 colours found.
Can you send me some example files?
*bump* Some small updates from today:
Template picker for image editor:

Open image files from main editor, which opens the sprite editor.
Remove pen tool, and just make the pencil do what the pen did.
Double-click to insert color in xLIBC color picker.

Download at the place:
http://merthsoft.com/Tokens.zip
If xLIBC 32 color images eventually supports custom palettes (specified by the user, so that the image uses that palette instead of the defaut), do you think you could add support for that in TokenIDE too?


Also, in the future, it would be nice to have an xLIBC map editor, because Mappy is sometimes unreliable >.<
Yup, I'll be adding support to the 32 color images as soon as I get some samples from tr1p (see previous posts in the thread).

As for a map editor, I've been working on it intermittently. I'm trying to figure out the best way to go about doing it. Maybe I can check out Mappy for some inspiration.
merthsoft wrote:

Pretty printing while typing:

The way this works is it detects if you typed an "Alt" token, and if you did it replaces it with the "Main" token. Right now those are the only tokens that have their prettier versions as their main, because I used them in testing. I'll switch 'em all out eventually.


Any chance of that switch being made soon? If not, I'll probably try it myself.

EDIT: Also, I was just playing with syntax highlighting rules, and noticed that I had a style called "Comment" in AxeTokens.xml. It didn't seem to do anything, but that's because I never actually assigned it to the comment character. But after I did, it changed the comment character's color, but still not the code on the rest of the line. Am I doing something wrong in expecting this to happen?

EDIT 2: It also appears that, if the first token in the file starts with a space (e.g. " and " or " nCr "), it doesn't get tokenized.
Quote:
Any chance of that switch being made soon? If not, I'll probably try it myself.

Yeah, I need to do that. Probably this weekend. If you beat me to it, I'll gladly take your changes, but I'm probably just going to write a program to swap them for me.

Quote:
Also, I was just playing with syntax highlighting rules, and noticed that I had a style called "Comment" ...

"Comment" is the style of the Comment Character lines, so by default, likes that start with "//". If you have a token with a style of "Comment", I'm guess it would screw up.

Quote:
if the first token in the file starts with a space (e.g. " and " or " nCr "), it doesn't get tokenized.

Huh, you're right. I'll have to fix that. Weird.

What I've been working on today:
merthsoft wrote:
Yup, I'll be adding support to the 32 color images as soon as I get some samples from tr1p (see previous posts in the thread).

As for a map editor, I've been working on it intermittently. I'm trying to figure out the best way to go about doing it. Maybe I can check out Mappy for some inspiration.


For a map editor, the thing to keep in mind is that we can use two appvars for 256 sprites total. However, one major issue with Mappy is that you cannot shift sprites around in the sprite sheets, only replace existing sprites. The feature to shift a bunch of sprites around to add a new one between them doesn't work. This is a serious problem for game collision detection because if you ever have to add extra floor tiles to your game and the slots for those tiles are already filled with sprites that are already used in game, then you are in big trouble: You have to redo the entire map from scratch.
Hmm, that sounds like a useful feature: being able to remap the, well, map. What you can do now is shift+click when doing flood-fill to replace all instances of the tile with the selected tile, like this:
merthsoft wrote:
EDIT: Got some files from tifreak that came with his calc. They are 22245 (268*83+1) bytes long, so the correct dimensions are 133*83. The first two bytes are something, I'm not sure. The first byte is always 0x81. The next one I'm not sure what it is.
Has this been solved? If it's still unsettled, it sounds like I should re-read my SC3 source code to make sure I accurately told you what it does (since TI-Connect accepts SC3 Image files).
Not really. I can generate the files in such a way that wabbit can open them, but TI Connect says they are invalid. The size you told me was wrong, and there seem to be a couple bytes at the start that I can't figure out. Here's an image that I generate that wabbit can send just fine and display, but TI Connect complains about.
merthsoft wrote:
Hmm, that sounds like a useful feature: being able to remap the, well, map. What you can do now is shift+click when doing flood-fill to replace all instances of the tile with the selected tile, like this:


Is this a new feature or is this still in production?
The map editor is still being worked on. The shift+click when doing flood-fill to replace works in the sprite/image editor, though.
*bump* It's now available. The workflow is a little weird, but it works similar to the sprite editor. You can either start a new one, in which case you get an empty 20x15 map, or you can highlight text in the main editor and start the map editor. When you do that you'll be prompted for the width and have to enter that in.
Once it's started, goto File->Add Tiles, and select the appvar that defines the tiles. If your map takes two appvars for all of its tiles, do this for each appvar, in order.

I've also added a new tool called the pattern tool:

Left-click and drag to define the pattern, left click again to place it. Right click to clear the pattern.

Download at the place:
http://merthsoft.com/Tokens.zip

Quote:
[04:46] <tr1p1ea> merth: its worth noting that my sprite sheet actually isnt layed out that way
[04:47] <tr1p1ea> http://img.ourl.ca/testtiles.bmp <-- that is my image
[04:47] <tr1p1ea> its just that you reverse engineered the sprites from the appvar i think
[04:47] <tr1p1ea> they are layed out in sequential order in the appvar, which is why it works either way [if reverse engineered]
[04:48] <tr1p1ea> but it was intended that they follow the standard layout
[04:48] <tr1p1ea> incidentally there are some serious incompatabilities with existing map making software, since going left to right, top to bottom is a universal standard
[04:49] <tr1p1ea> if Tokens was to arrange images the same way, peope could use a multitude of different, existing tilemap makers

It would've been helpful to be told this back when I was first implementing this and asking everyone for opinions Neutral I'm fairly certain I loaded the sprites in that order because that's the order the pixel data itself is stored in, so I just went with it. I don't like the inconsistencies of going column-first for the pixel data, but row-first with the actual sprites. It leads to this sort of confusion--not having the initial sprite image didn't help either. Especially given this post where you say they're stored by column. I guess ultimately I'm just trying to justify why I did what I did. It probably doesn't matter...

I think at this point there are a lot of programs that do it my way (at the very least, the programs I've released), that it might get really confusing for people if I switch it. I'm not sure what the right thing to do is.
merthsoft wrote:
Not really. I can generate the files in such a way that wabbit can open them, but TI Connect says they are invalid. The size you told me was wrong, and there seem to be a couple bytes at the start that I can't figure out. Here's an image that I generate that wabbit can send just fine and display, but TI Connect complains about.


1) Header: The type is 0x1A, the variable prefix is 0x3C, the version must be 0x0A, and the archived flag must set (0x80).
2) Data prefix: To quote Ben Moody (FloppusMaximus): "The variable must begin with the byte 81h, which I guess is meant as a
format code". That was my independent deduction as well.
3) Dimensions: The image size is 134x83 pixels. The rightmost column is not displayed. Each pixels is 16 bits, so the total size is 1+22244 bytes of data.
4) Format: Rows are stored left to right, bottom to top (BMP-wise). Each 2-byte word contains 5-6-5-packed RGB color.

Hope this helps! Sorry for the inaccurate info.

Edit: And the MAP FEATURES LOOK REALLY COOL!!!
Okay, awesome. Thanks to Kerm, color image (and picture!) saving now works correctly.


Download at the place:
http://merthsoft.com/Tokens.zip
Great work on the map editor! Looks awesome and will take care of any issues with 3rd party editors. The way the sprite data is stored at a bit level has led to the confusion, which is my bad.

Either way, the toolset is set to make developing the 84C a breeze Smile.
tr1p1ea wrote:
The way the sprite data is stored at a bit level has led to the confusion, which is my bad.
Nah, it's not a big deal. I should've confirmed with you anyway. It's all good now, anyway ��
Quote:

Either way, the toolset is set to make developing the 84C a breeze Smile.
That's the hope! Glad you think so too!
Great job Merth on this map editor! Very Happy
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
» Goto page Previous  1, 2, 3, 4, 5, 6, 7  Next
» View previous topic :: View next topic  
Page 4 of 7
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement