A difficult problem. New flexible bitmap driver if it can be solved. *** Now So

Kye

Hey guys,

I've been working on a barbones vga bitmap driver for the prop that can have many resolutions and can be set in the constant section of the code.
I have two variants for it. 2 color and 4 color.

However, I can't seem to get the resolution idiot proof fixing code to work properly for all cases. The problem is that all the code needs to be done in constant expressions in spin so I only have acess to math operators and nothing else. This is making it difficult for the code to work in every case.

Bascially I need to do this... The user supplies a value for each of the below constants and then I need to do what I say in the comment.

Horizontal_Pixels = 320 ' The driver will force this value to be a multiple of and less than 640, and divisible by and greater than 32. 
Vertical_Pixels = 240 ' The driver will force this value to be a multiple of and less than 320, and greater than 0.

So, for whatever value the user supplies for Horizontal_Pixels pixels I need to find a value near the value they input that is a multiple of 640 but not greater than it and is divisible by 32 but not·less than it.

For the Vertical_Pixels I need to make sure the value is a mulitple of 320 but not greater than it and is greater than 0.

...

So, in the above I mean a multiple loosely as I mean that·(320 / Vertical_Pixels) needs to be an integer and (640 / Horizontal_Pixels).

...

Getting the greater or less than parts are easy with limits. But I still can't seem to find a way to make the driver bullet proof so that you cannot enter a resolution that will fail. (The idea is that the resoltuion will be modified but still run instead).

Anyway, thanks for helping!


·

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,

Post Edited (Kye) : 10/26/2009 7:00:45 PM GMT

potatohead

Here's an example from my older 8x8 driver that did this kind of thing:

[noparse][[/noparse]code removed as it's not relevant!]

You should be able to use modulo, trunc, and other math operators to get this done. Also, don't forget you can start with a float, assign a truncated value to an int, and use the logical and and shift operators to do a lot. Cardboardguru did this early on, mixing DAT and CON code areas to manupulate user input constants. A whole lot can be done.

You can use multiply as if then too. Use round and trunc to get a base integer, then multiply it by something that would equal 0 and add that, for a conditional addition.

And I have to ask, why not just have a few lines of SPIN that perform this task, that calls the driver when done? It's a lot easier than the constants. Which I found very difficult also.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!

Post Edited (potatohead) : 10/26/2009 7:52:39 PM GMT

Kye

I'm going for the smallest code size possible.

Mmm, well, I'll keep this tread alive if anyone has any ideas.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,

localroger

Kye, I think the word you are looking for instead of "multiple" is "factor."

Factoring is tricky, but in this case there are a small enough number of factors of 640 greater than 32 that the simplest thing would probably be to make a list of them and do a search for the value closest to what was input.· I get 640, 320, 160, 128, 80, 64, 40, and 32 as the only possibilities.

potatohead

OK then, that makes sense.

I'll hack on this a bit later today with the CON section. Do you mind if a few DAT's are used to hold some values during constant computation?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!

rokicki

Something like the following should work fine:

y = ((x => 640) & 640) #> ((x => 320) & 320) #> ((x => 160) & 160) #> ((x => 128) & 128) ...

potatohead

That's simple, and rather easily debugged. I'm consistently amazed at the flexibility of SPIN expressions.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!

Post Edited (potatohead) : 10/26/2009 5:13:36 PM GMT

Kye

Great idea rokicki. I was going for a general mathematical form, but that works much better.

Okay, I'll try to get this done and finished soon.

...

I'm trying to keep the amount of basic functionality very small so that the driver's library does not eat up to much code space since there are pretty much an infinite amount ways to do things with graphics.

That said, am I missing anything that needs to be in a vga driver? I'm trying to make this one very flexible.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,

jazzed

@Kye,

Nice work so far. Looks like one could make some nice GUI elements with this ... something I've been looking for [noparse]:)[/noparse]

A small Spin character drawing routine would be nice to have and is easy to write using the character rom and pixel plotting.

How much HUB RAM is available with the driver running?

How hard would it be to make a TV variation? TV might not be nice as VGA, but it could find general use.

Kye

I have no clue how to program the TV driver part. I've only learned how to do VGA crazy well.

If you look carefully in the drivers syncing sections it's setup so that the driver can do alternative stuff while it is syncing easily. I used the same framework in this code from another full featured vga driver I made that has a mouse cursor and display in one cog.

So, this driver will be great for building anything you want from it.

For example, you can have a display buffer using just one long if you want. The resolution is then 32 x 1 mapped to 640 x 480.

Pretty sweet. I'll have a four color one coming up also soon.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,

Kye

The Solution:

  Horizontal_Scaling = (((Horizontal_Pixels #> 0) =< 32) & 20)  #> (((Horizontal_Pixels #> 0) =< 64) & 10) #> {
                       }(((Horizontal_Pixels #> 0) =< 128) & 5) #> (((Horizontal_Pixels #> 0) =< 160) & 4) #> {
                       }(((Horizontal_Pixels #> 0) =< 320) & 2) #> 1)
 
  Vertical_Scaling = ((((Vertical_Pixels #> 0) =< 1) & 480) #> (((Vertical_Pixels #> 0) =< 2) & 240) #> {
                     }(((Vertical_Pixels #> 0) =< 3) & 160) #> (((Vertical_Pixels #> 0) =< 4) & 120) #> {
                     }(((Vertical_Pixels #> 0) =< 5) & 96)  #> (((Vertical_Pixels #> 0) =< 6) & 80)  #> {
                     }(((Vertical_Pixels #> 0) =< 8) & 60)  #> (((Vertical_Pixels #> 0) =< 10) & 48) #> {
                     }(((Vertical_Pixels #> 0) =< 12) & 40) #> (((Vertical_Pixels #> 0) =< 15) & 32) #> {
                     }(((Vertical_Pixels #> 0) =< 16) & 30) #> (((Vertical_Pixels #> 0) =< 20) & 24) #> {
                     }(((Vertical_Pixels #> 0) =< 24) & 20) #> (((Vertical_Pixels #> 0) =< 30) & 16) #> {
                     }(((Vertical_Pixels #> 0) =< 32) & 15) #> (((Vertical_Pixels #> 0) =< 40) & 12) #> {
                     }(((Vertical_Pixels #> 0) =< 48) & 10) #> (((Vertical_Pixels #> 0) =< 60) & 8)  #> {
                     }(((Vertical_Pixels #> 0) =< 80) & 6)  #> (((Vertical_Pixels #> 0) =< 96) & 5)  #> {
                     }(((Vertical_Pixels #> 0) =< 120) & 4) #> (((Vertical_Pixels #> 0) =< 160) & 3) #> {
                     }(((Vertical_Pixels #> 0) =< 240) & 2) #> 1)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,

trodoss

@Kye,
Looks like it will be a great driver!

I tried the example code though, and certian refrenced methods seem to be missing:
changePixelOnColor
plotOnPixel
...Maybe those were in there for testing and are not in the driver?


I would agree with jazzed -- a nice character drawing routine (8x8 ? 16x16?) would be nice.

trodoss

Here is a·quick example using the 'AIGeneric-style' fonts.
--trodoss

[noparse][[/noparse]Edit:] Accounted for the 'AS_VIEWED' portion of the AIGeneric fonts (first 8 bytes of char $20), so that 'Space' will display correctly.

Post Edited (trodoss) : 10/26/2009 9:19:13 PM GMT

Kye

I can just use the prop font... Mmm... Its a maybe on characters however.

I'm trying to avoid making any asumptions on the driver's use except for the fact that it will be run with spin. I want to just give it base functionality... But I guess character drawing can be considered that since its on the prop chip itself.

... Okay, I'll include it, but its gonna be a bit weird... due to all the calculations that must be done. Maybe I'll make it so that the asm driver has a print funtion and FIFO buffer built in so that it goes fast and is flexible.

But then that's more complex... Mmm... We'll see.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,