Jump to content
Opry99er

Bitmap image conversions

Recommended Posts

I remember seeing (several months back) a program which converted photos or artwork to TI bitmap images and exported assembler data. I've been searching the archives and don't remember what the program was called...

 

1) What is the program

2) How intuitive is the program

3) Who wrote it

4) Is it freeware

 

Thanks guys... I'm not in a big rush now, but in a month, I'll be needing to start work on some of these images. Thanks in advance

Share this post


Link to post
Share on other sites

As an example... see the below picture. Of course, this one is far too large, but it can be scaled back... Also, even though it was listed as "free to use" on the desktop site I visited, it's obviously copyrighted... This is just an example of the style of artwork I'm looking for. =)

 

dragonslayer.jpg

Edited by Opry99er

Share this post


Link to post
Share on other sites

Downloaded and converted a few images. Awesome.

 

Tursi, if you're reading... what is the significant difference between SKELETON.TIAC and SKELETON.TIAP? The hex looks different, so I'm sure something is different... just wondering if I need both, or just one... I'm going to try to write in a bit of a tester to my XB program to try to load a bitmap image from XB. =)

Share this post


Link to post
Share on other sites

Would it be possible to store individual images to disk and then have them called and displayed from XB?

 

I am thinking how cool this would if the images could be used in a text adventure game that was otherwise completely written in XB.

Share this post


Link to post
Share on other sites

zombskelbmp.png

 

Here's the best conversion I could do... I need to find either very large pictures or those with few colors and little detail (or so it seems)... The converter is easy peasy to use... Just trying to get the hang of selecting good candidates for conversion. =)

Share this post


Link to post
Share on other sites

Perfect answer, sometimes... thank you. =)

 

Yes... I believe it's possible, but I'm not sure if we even have 12k of totally free VDP RAM while XB is running... do we?

Share this post


Link to post
Share on other sites

Would it be possible to store individual images to disk and then have them called and displayed from XB?

Well, I guess you could swap out the almost 13K VDP RAM (or just all 16K) and put in the picture, wait, then restore VDP, and continue XB and disk operations as if the bitmap display thing never took place.

 

Edit: The code to do that, the picture and buffer would severely restrict the size of your XB (running) in more than one way to something less than 7K.

 

:cool:

Edited by sometimes99er

Share this post


Link to post
Share on other sites

Would it be possible to store individual images to disk and then have them called and displayed from XB?

Well, I guess you could swap out the almost 13K VDP RAM (or just all 16K) and put in the picture, wait, then restore VDP, and continue XB and disk operations as if the bitmap display thing never took place.

 

:cool:

Forgive me - because I don't have any understanding of how this could be done (I am just an XB guy), or even if it is practical - but how long would such a process take to execute and return back to a BASIC environment? Could it be possible to create something along the lines of the way graphics were displayed in the C64 game Twin Kingdom Valley?

 

Or is the idea just so unpractical it wouldn't be worth the effort?

Share this post


Link to post
Share on other sites

I don't think it's that unpractical... remember that in assembly, VDP writes happen super super fast. This bitmap image would have to be "called" or "drawn" from an assembly routine, and (even though full screen bitmap images are large and bulky), it would still happen super fast. I'm going to start testing with an assembly program. Just need to learn how to initialize GMODE2 and learn the format for writing on a pixel basis. =)

Share this post


Link to post
Share on other sites

I think it has been done before.

 

You would of course have to call a special user written machine code routine to freeze XB, swap things around, and return safely. All of this would take a fraction of a second. Some good knowledge of where XB is operating in VDP, Low and High Memory is required. Reading the picture from disk could probably be done in the above machine code routine (using disk routines usually uses VDP, so I guess we need a CPU RAM buffer), but will only be as fast as the disc usual is with a 12K transfer. Assuming I'm right about having to copy 13K of VDP memory (to another buffer), you're only left with a max of about 7K for your running XB (stored XB is often smaller or much smaller (if you're using an array or something)).

 

Edit: Oh, forgot about compression techniques. I had some 12K pictures reduced to about 5K using super simple RLE. Like I did with this "simple" picture (not too many details allover). Would leave another 7K free for XB.

 

chilipeber2.png

Edited by sometimes99er

Share this post


Link to post
Share on other sites

7K wouldn't allow a lot of bells and whistles, but I think the concept is real exciting.

Well, as I said I don't know XB that well. Can't you simply have XB load another XB, that takes care of displaying etc., and then call the original XB - or is it something with "merge" that confuses me. Never got to technical with XB (I was MiniMem guy).

Edited by sometimes99er

Share this post


Link to post
Share on other sites

I think the issue here would be speed. You would have to save all your program variables, execute the XB program to display, reload the main program and then re-load the program variables.

Share this post


Link to post
Share on other sites

Ah, I think those people with memory expansion beyond the usual 32K or maybe GRAM Krackers would have done something like this with XB. That would certainly make things speedy (when all things have loaded).

 

:sleep:

Share this post


Link to post
Share on other sites

The nice thing about my needs... The only time bitmap images are needed are:

 

1) before the game starts (introduction)

2) between worlds (intermission)

3) after the game ends (conclusion)

 

So... during intermission, all my variables are parsed to disk anyway... it's just about the only way I can think it would be possible. This was the intent from the start... I hadn't thought about using these images during program execution... With Beryl, each world is its own XB program, so calling bitmap images between worlds is certainly at least possible IN THEORY. =) We'll see what I can come up with reading through some of my manuals...

Share this post


Link to post
Share on other sites

Holy crap, you guys really run with it.. I'm not sure I can answer without repeating information.. but to try and summarize:

 

First: when converting, hit the "perc" button - that enables perceptual color matching. Especially for images that are a little lower in contrast, the result can be much better. It's less mathematically accurate, but 9 times out of 10 it looks better. ;)

 

Another useful option in my converter is in the Options menu, if you don't mind cropping the image some, change the 'Fill Mode' (for most images you want 'Middle', portraits are often better with "top/left"). This zoomes the picture up to fill the screen, cropping whatever falls off the edges. With more pixels to work with, it often gives a better result.

 

As Sometimes notes, the TIAC is the 6k of color data, and the TIAP is the 6k of pattern data. You have to load both into VRAM to display the image. As for compression - the converter can save the files with RLE compression - works well for simpler images and not so well for heavily dithered ones. You need to write the uncompress code in that case, of course.

 

As for making it work with Extended BASIC... that does get tricky. The Missing Link proved that it's possible to have a nearly full color bitmap screen working in conjunction with Extended BASIC, but it sure had to do some manipulation! My thinking is that buffering VRAM would leave you with so little CPU memory for your program that it might not be worth it... an assembly program might be able to buffer VRAM to disk instead, and then load it back before exitting, but I guess that'd be fairly slow?

Share this post


Link to post
Share on other sites

Well, there will be not much of a program, actually.... It just displays a bitmap image, waits for the user to hit enter--- then loads another bitmap image from disk and display it, then it has a

 

RUN DSK1.NEXTWORLD

 

 

Basically, the XB program I will write might be no more than 10 lines or so. :)

That's it... The only reason I want to do it all in XB is that I want to call one program from the next in a chain. That possible, perhaps?

Edited by Opry99er

Share this post


Link to post
Share on other sites

hmm. It'd work, but it'd be a bit slow. (not so bad when we port your game to run from cartridge in the distant future, though ;) ).

 

So to be clear, you want a way to chain to an XB program that displays the picture, and then chains to another (configurable) XB program. Yes?

 

I have an idea.. not sure if I can pull it off...

Share this post


Link to post
Share on other sites

Yea man---

 

Program flow something like...

 

 

1) bitmap images&text (CALL LINK)
   --RUN DSK1.WORLD1
2) world 1
   --RUN DSK1.INTERMISSION
3) intermission bmp images
   --RUN DSK1.World 2
4) world 2

 

So 4 XB programs called from one another per disk. 2 which are designed as "intermission programs" and two "world" levels.... Of course the disk will contain several other items, but 4 executable XB programs run in a series, supported by all the other stuff on the disk. :)

Edited by Opry99er

Share this post


Link to post
Share on other sites

Forgive me for not getting this all to production quality before going to bed, but it's 6:30am and I do have stuff to do in the daylight if I can! ;)

 

XBTEST.zip

 

Drop this bad boy into Classic99, load and run through Extended BASIC. Press "Enter" to exit.

 

I'd like to know if it works on other emulators/real machines - and most importantly, whether disk access works on them after the program exits. (ie: just try to OLD another program). I did a little code to take disk into account but haven't tested it yet.

 

I tested that it chains successfully in Classic99 but it made a bad demonstration, so I changed the RUN "DSK1.TEST2" to a PRINT "SUCCESS".

 

More to come after sleep.

  • Like 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...