Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
Tags

Subchrist Software

40
Posts
249
Followers
1
Following
A member registered Jan 27, 2020 · View creator page →

Creator of

Recent community posts

Thanks for the suggestion MGB, yes, that sounds useful. Added to the todo list.

(1 edit)

Thanks for the suggestions, I am reliably informed that it already works very well on Mac using WINE or Crossover, not sure about iPad but the same solution may be possible.
With current sales barely enough to keep a cat in munchies, don't hold your breath for any alternative native versions, sorry.

One important tip (that I should probably make more apparent in both apps) is the importance of keeping char/sprite 0 and tile 0 empty (clear) when painting tiles directly, and especially when using expanded sprites in SpritePad.

I could say much  more on that subject but will just say that for now.

Hmm ok, well sprites are never "recognised" as expanded while you are drawing, sprites can only be drawn at their regular size, they can only be instructed to appear expanded (in tiles) where they have space to do so (and only "into" zero sprites).

Maybe try ignoring the pixelling tools in the tile editor for now and just draw sprites in the (sprite) editor, then "stamp" them into the tile using the sprite-brush tool.

I can't really see what you are trying to achieve but you may just be going about it the wrong way.

(probably obvious tip:  expanded sprites do not gain any extra pixels, it's just a stretching thing).

Hi,

Sprite expansion can only happen (in SpritePad at least) when the sprite is placed into a tile.

For X-expansion to occur there must be a "zero" sprite in the cell to the right of it, similarly for Y-expansion to occur there must be a "zero" sprite in the cell below.

I hope that helps.

Also worth mentioning is the fact that while the addition of 'per-map-cell' (and/or per-tile-cell) colouring methods + the abilty to directly paint colour to the map/tiles might be intuitive enough for the text modes (just 1 matrix colour), it almost certainly would not be for the bitmap modes (2 / 3 matrix colours).

So on balance, I would have to conclude that offering 'per-cell' matrix colouring as a project data export option (only) would be the right choice.

(3 edits)

Hi, thanks for the feedback, yes the decision was taken many years ago purposefully NOT to include a "per-map-cell" matrix colouring method, with CharPad being primarily designed as a game-map editor the feeling was that few games would need/use such a method due to the effective doubling (or at least a 50% increase, 1 nybble per cell) in the size of required map data.

This and also the requirement for the user to manually paint the map colours as well as the map characters were the main reasons for it's omission.

However it actually IS something that has remained on the todo/maybe list and while it might not get added as a general feature, it MIGHT get added as an export option at some point,

ie. if you have a project using the "per-char" colouring method, we may add an option/tool that would create a converted set of data for a "per-map-cell" colouring method (for export/use/viewing on the C64), this would obviously allow a reduced number of character images in most cases as all of the colour data would be pushed over to the map.

It may not be the solution you were hoping for but it's the one that is most likely to happen as adding such a colouring method (and probably also "per-tile-cell" would likely take years to complete as general features.

Thanks so much for your support :) we hope you find the apps useful, there's always an update in the pipeline but do let us know if you have any suggestions etc. Cheers!

Hi, thanks for your suggestion,

Something like this (a sprite layer) has been on the todo/maybe  list for quite a while, the idea has just taken a back seat to the more char-related features (of which there is, and has been, an enormous amount to do).

I'm sure at some point there will be a merging between SpritePad and CharPad to turn the tool into more of a programmer's "level editor" than the tile-map editor that it currently is.

The idea is on the list!

Hi,

I'm afraid the answer to that is no.

I *will* consider it (and possible alternatives) for a future version but it is the kind of feature that could become very complicated very quickly and the current set of display modes and colouring options are really quite challenging as they are.

I have so far found the "one project/one map/one palette" model to be the least confusing for myself and for users so perhaps there is another way to tackle the problem.

Hi,

Thanks for the suggestion.

While CharPad (Pro) *does* support custom palettes and includes a built-in palette editor where they can be created/saved/loaded and thereafter will draw all graphics using it, it will not currently display the tweaked palette in the Project window's colour selector, instead always showing the same (pre-drawn, c64) palette image(s).

I have made a note and will definitely look into it.

Thanks for clarifying that.

(2 edits)

When you say you have to scale and resize "the window", which window do you mean? the map, the charset?, the whole thing?

As every project is using different size charsets, tilesets, maps then I don't quite see how this would be helpful unless a layout were somehow saved for every project.

The main (parent) window itself should be starting maximized.

Version 3.10 is now available. Merry Christmas!

Hi frodewin, thanks for the bug report, yes you are quite right, there is a fault, it is present in the Win32 and Win64 builds of CharPad Pro 3.09.

The .NET build is unaffected.

I have just fixed it and will try and get a new version up tomorrow.

Hi, thanks for posting, the issue has been noted, I will investigate and try and get a fix into the next release.

Hi, thanks for the suggestion, we will look into it asap.

Hi thanks for the report, we found this bug a few weeks ago and it has been fixed for the next release, it is present in CharPad 3.01 and related to some internal changes with the number of colours stored per char.

An update is coming in a week or two.

(4 edits)

Hi, thanks for the feedback.

#1, yes I take your point, hex offsets would probably be more useful.

#2, CharPad will 'auto-correct' (tile/map data) for all operations that move chars/tiles around, ie.. cut/paste, delete/insert, compress/decompress.

If the chars/tiles for a font need to exist in the same charset/tileset as a game map (but are not used directly by it) then it is best to keep the font as a separate project and simply copy/paste (from the font project) into the game map's project when you need to combine them (auto-correct will be performed).

If you need to rearrange chars or tiles within a project then this can be performed by swapping items (CTRL + RIGHT mouse button), auto-correct will be performed.

I hope that helps.

Nice! you clearly have a natural talent for this stuff :) I would be happy to include a few examples of your work in the packages if you ever have any spare/unused bits and pieces that you would like to show to our users. 

Hi Mrmo, 

For the time-being you will probably find it easier to work on the overlay first, ie. a black outline, then move to the underlay sprite and fill in the previously drawn shape (where both will be visible in the editor).

In the current system, sprites can only "have" overlays, so both sprites will only be visible when working on the "underlay".

Thanks for raising the issue though, I will take a good look at it and see if there is an improvement to be made.

Thanks for letting me know, it's a bit strange as nothing has actually changed AFAIK, the .NET assemblies have never been signed.

I just tried it on a spare Win7 machine, no warning was shown.

Thanks for letting me know, seems like the website is offline for some reason.

Thanks for the bug report Maciej, I have tracked down the problem and nailed it. The tile editor's constructor was zeroing the current item (1) after loading a new project. The fault was present in the Win32/64 versions and also affected SpritePad and the last released CharPad 2.xx releases. I will put out some updates in a few days. Nice catch ;)

Hi, thanks for posting.. could you be a bit more specific? which CTM version are you exporting to? what is the resulting problem? if exporting to CTM5 then I can tell you that this format does not support tile tags or names, I should probably put in some friendly warnings about unsupported features when exporting to older project formats.

(1 edit)

Hi,

Yes it's posible at some point, the idea has been on the todo list for some years now but there always just seems to be endless  amounts to do just for the C64 version!

Certain concepts such as the 16 colour palette and particular features of the VIC-II are quite tightly woven into the current system and trying to squeeze in support for another platform would likely break a lot of existing stuff.

So yes it's possible but would require a great deal of work and most likely need it's own separate version rather than making the current tools more flexible to accommodate it.

I once owned a plus4, I liked it and it is definitely something I would like to do.

ps. Thank you for your support, it is greatly appreciated.

Hi, yes all the CTM project file formats (1-7) are described in the html help files that are included with CharPad Pro / Free.

(3 edits)

Hi, 

Thanks for the suggestion, yes it's a good idea and I'm fairly sure it's something that has been on the "todo (maybe)" list for some time. 

CharPad includes the maps from 'Hawkeye' and 'Flimbo's Quest' which both use colour switching in their actual games and so don't appear quite correct in CharPad. 

(The lowest tile rows for those games are dynamically recoloured using a raster IRQ/colour split)

As it may (sooner or later) be desirable for a "split" to occur on any raster line (ie. mid-tile or mid-char) then I would probably rule out doing it in the map editor or per-char/tile and instead have something like a "Screen Emulator" window that could be configured with the desired splits/colours on the chosen raster lines.

The more I think about it, the more I think it's something that would be far simpler to do using some native C64 code and ie. the VICE emulator.

I know ideally you would want it to be immediately visible IN the map editor but I can't see that happening to be honest.

CharPad's map editor/renderer is not really "line based", is fully resizable and does not actually represent a "screen".

I will consider it further!

(7 edits)

Well, it's a Commodore 64 graphics editor, those colours are kept fixed because they fairly accurately represent the VIC-II colours, even if the palette is altered for personal taste.

It's especially important when using multi-colour mode and the 'Char' pen as the palette image then changes to indicate the "multi-colour" versions on the lower row (as seen in your image above).

ie. If you are using the app for non-C64 work then the concept of the Char pen having 8 hi-res + 8 multi-colours fails and a  recoloured palette image would make no sense.

May I ask what platform you are pixelling for?

(1 edit)

Just hit the 'Ok' button at the bottom of the 'Colour Palette Settings' dialog.

Hit 'Cancel' (or press the 'X') to exit without making any changes. 

If you have a project loaded you should see be able to see the colours change as you tweak the settings.

(2 edits)

I hear ya.

 I've been using GIMP today and that has lots of single key shortcuts which obviously must get blocked during any actual text entry.

I will look into it for a future version.

ps. If it helps you can already use the space bar to temporarily switch to 'Pan' mode on the map editor, and use CTRL+wheel for zoom as described earlier.

(9 edits)

Hi, thanks for the feedback, one reason that single keys are not used as shortcuts is that the map editor has a text-entry tool that accepts most single alpha-numeric keys as input, so single key shortcuts such as WASD (or cursor keys) would not be possible there. Another is that no dev environment I've ever used has allowed single keys other than F1-F12, Ins, Del etc to be specified as shortcuts (in design mode at least), I'm not saying it isn't possible but wouldn't be practical for the first reason.  

nb. All windows that have a 'zoom' op already have a shortcut for zoom in/out, try CTRL + mouse-wheel.

F1-F5 are currently used for colour selection.

Thanks though, I will think about your requests further.

CharPad and SpritePad are both "portable" apps and so require no installation but this also means their project files are not automatically associated with any particular executable(s).

I'm sure it's possible to make an association manually which I'm guessing is what you have done.

That's fine but one problem with doing that is that when a new version is released you will likely have to make the association between the file type and the (new) executable again.

Personally I never bother associating files with portable apps but I will look into the issue for the benefit of those people that do.

Thanks for bringing this to my attention.

(1 edit)

Hi, 

Thanks for the feedback. 

The main reason that such a colouring method is not supported is because of the sheer amount of memory it would require, ie. twice the map size in bytes.

In ECM mode you automatically get four different (background) colour versions of each of the 64 chars, but yes if you use "per char" colouring in any display mode you would potentially need to duplicate chars to get a different (foreground) colour version.

I will have a think about the problem and put it on the todo/maybe list.

Hi. 

Char material values (0-15) are recorded in the upper nybbles of the character attribute bytes.

In the included Help folder, the file "File IO Exporting.htm" describes this and a few other things.

Interesting,  that one that isn't on my todo list already (!).

I have added it to the list, in the mean-time you can try...

Import/Export... Text/Asm... Export Char Usage Statistics.

Yes it's a bit more hassle than having the usage count immediately visible in the set but should help a bit.

Hi Superrune, 

Thanks again for you suggestions, the addition of a "modified" flag coupled with a regular Save op have been on the todo list for a while now, it can be a tricky task in an app that stores multiple data blocks like this and doing it badly and ie. failing to flag a change in some element would be quite embarrassing. on the other hand I don't want a system that is sloppy and flags change where there is none,  ie. blue pixels painted over blue pixels. 

I will give it some thought and try and get some solution fitted soon + I'm very sorry to hear you have lost some work.

(1 edit)

Hi Superrune, thanks for your suggestion, I will look into that for a future version (I find key handling and avoiding ie. shortcut conflicts to be a very tricky business in dot net),  in the mean-time you can click the middle mouse button (or wheel) to pick a char/tile when using the map editor (if you have one).

Hi Superrune, thanks for the suggestion, you are the 2nd person in the last few days to request that feature, so yes it's on my todo list for the next release.

(1 edit)

Thanks :) you can try running it using Mono or Wine on Linux/Mac, I don't use those systems but I know some people have had success with it.