--deleted--

Starting to draw up some town/village stuff


Also- spells!

Messing around with UI and colors..

Quote from: DarkestEx on October 17, 2015, 08:47:16 PM
Wooha, they look nice

Can I reuse some sprites for microcat games? Or might you maybe make some yourself?

Feel free to use any of my art as long as credit is given.

Here's the full spritesheet:


And if there is something you would like me to try and make,  let me know.

Quote from: Araidia on October 14, 2015, 08:07:22 PM
Nice art, LDStudios! I wish I had that kind of determination.
(Is this a game being made or is it just art?)

I've had some ideas for a game, and even threw together a dungeon generator that you can walk through- but no promises yet that anything will happen.

Quote from: p4nix on October 15, 2015, 09:10:54 AM
Sadly, because this art could be used in games really good. I mean, this is good enough for goodselling retro-indie-games in my opinion

Quote from: Streetwalrus on October 15, 2015, 09:22:18 AM
Yes indeed, these sprites are top tier 16 bit material. Great job.

Thanks very much for the compliments ^.^

I made some more characters

(Thief, Sorcerer, Assasin, Soldier, Archer, Lizard, Mage, Skeleton, Jiangshi, Paladin, Bishop, Orc, Goblin, Ghost, Slime, Bat, Wolf)

It's a bit cramped, but I think it looks better when scaled up to 24x24 rather than 16x16, because you can actually see the artwork.

The enemy information bar would have to disappear when the cursor isn't hovering an enemy.

Any game that doesn't overexhaust the timer can usually run at a pretty good speed. Because in a roguelike you really only need to update things whenever the player makes an action, I don't think speed would be an issue.

With nspire lua dimensions:


and a few more characters..

Some roguelike art,

Quote from: annoyingcalc on October 08, 2015, 10:37:49 PM
Sure, once I iron out the major bugs and can access my laptop instead of this iPad I'll send a copy.

Also, currently there is no greyscale, partly due to my limited artistic abilities. If anyone wants to help with graphics that would be nice. However, in my opinion it looks a bit nicer than Sam Heald's right now.

If implementing grey scale is really just a matter of artistic abilities, tell us the sprites you need at what dimensions and I'm sure people will help

Quote from: Adriweb on September 28, 2015, 03:14:31 PM
If you use images extensively (especially if big), you WILL feel the difference between OSes. Benchmarks don't always reflect reality... A simple test is using mViewer GX Creator in API level 1.0 (string images) and in API level 2.3+ (resources images)
I think another big difference is the loading time, in favor of the image resources. But I don't have timings for that.

I understand that the difference between OSes and image drawing is significant, but from what I've seen using image strings on newer OSes doesn't seem particularly different than using image resources with them. That being said, I suppose the difference in speed could be more drastic if you "use images extensively (especially if big)".

Quote from: Adriweb on September 28, 2015, 03:14:31 PM

Quote-Image data embedded directly in the code makes transferring code between editors and people much easier

Sure, but needing to do that pretty much never happened to me, in the past few years... Use external editors and building scripts (However older Luna versions didn't support the new image resource system)

This may not be especially relevent to you, but I've run into the issue fairly often, especially when collaborating with others, or if coding on calc (in which case there is no way to use image resources).

Quote from: Adriweb on September 28, 2015, 03:14:31 PM

Quote-Image strings can be manipulated to manually reverse images, or replace colors within an image

True, though these techniques aren't extensively used.

These techniques might not be extensively used, but I'm not sure why not, because there is a lot we can do with them. I particularly mentioned this because a project I was working on a few months ago involved a small library to manipulate image strings in such ways, and I found it very useful.

Anyways, I wasn't trying to say you arguments were totally invalid, but I'm just trying to point out that there are plenty of arguments in each direction, and I definitely don't think that one method can be ruled out as worse than the other.

Quote from: Adriweb on September 28, 2015, 03:36:21 AM
The easiest way would be to install TINCS 3.2. It will generate some TI.Image resource in the old string format.
The format itself is known and documented by TI, in fact, as well as here: https://wiki.inspired-lua.org/TI.Image

But yeah, it's slow and annoyingly large, Image resources from 3.6 on are much better.
Supporting old versions seems like a rather moot point, The majority of people have 3.9 if not 4.0 (and some still have 3.6... Earlier ones are very rare)

I don't think it's fair to say so plainly that "image resources from 3.6 on are much better", both have their pros and cons,

Benefits of Image Strings
-Image data embedded directly in the code makes transferring code between editors and people much easier
-Images take up significantly less file size
-Image strings can be manipulated to manually reverse images, or replace colors within an image

Benefits of Image Resources
-Images are drawn slightly faster
-Easier organization, and images don't take up large parts of code in the editor

Your argument that image strings are "slow" in comparison is hardly valid, given Jim Bauwen's analysis that:

Used image: 320x240 full spectrum gradient

TI-Nspire OS 3.2.4

draw image string: 15.12ms

TI-Nspire OS 3.6

draw image string: 14.08ms
draw image resource: 14.51ms

TI-Nspire OS 3.9

draw image string: 14.16ms
draw image resource: 14.15ms

TI-Nspire OS 4.0

draw image string: 14.26ms
draw image resource: 14.21ms


In OS 3.9 and 4.0, the difference of .01-.05ms seems almost insignificant.

Really it's a matter of preference, but that's why I much prefer image strings, and also why I still use Student Software 3.2

I'm pretty sure imgstrs are supported in every apilevel, the only problem is that the newer Student Software doesn't have the button to insert an image that way- which is why I still use Student Software OS 3.2

Quote from: semiprocoder on September 11, 2015, 02:31:04 AM
I don't know how to make it compatible with previous versions, but you said that they work...

At the beginning of your code, set
platform.apilevel = desired apilevel
For OS 3.1 support, your desired apilevel is "1.0"
If I recall correctly, OS 3.2 = "1.2", and OS 3.6 = "2.0", but that might not be right.

Keep in mind though, that if you set your code to an earlier apilevel, you also need to make sure you only use functions available in that apilevel.
I think the one thing you would really need to change for this particular project is image handling to imgstr instead of resources.

Please use the code tags around your post when posting a large amount of code at once.
[ c o d e ] code here [ / c o d e ] (without the spaces)