Alternate Armstrong Boot-images

[Japa]

I want a pipe in the shape of the pandora logo that slowly fills up.

 

[PSyMastR]

OOOOOOOooo now that is a good idea Japa

 

[Username]

Why not have it for when you take it out of sleep mode instead? How often are you really going to do a hard reset?

 

[Vorporeal]

Holy crap guys. Stop forgetting about the fact that we're talking about ANGSTROM boot images, not BIOS boot images. Angstrom already has something in it for showing a boot image, the best thing would be to use (or slightly modify) that. There's no reason to write any code for doing the displaying if we're not making BIOS boot images.

Most boot splashes actually aren't iamges, but instead C modules. Why is everyone so afraid of C all of a sudden?
Look at Ubuntu: C modules in USplash.
Look at Fedora: C modules in Plymouth.
There are some exceptions, like Splashy, that use XML files for boot splashes, but almost all OSs I've seen so far use some kind of compiled code module for splashes (and none of them just use plain images, with nothing else). Which is a Good Thing®, because it means that your splashes won't lag.
You can of course use images in that C code, so it's not like stuff becomes more complicated just because you have to write a C module.

Now, leave the implementation of the splash animation to the programmers and continue spitting out more ideas (Just don't expect it to be possible to drop a .psd in some folder and just use it as a splash anim.)


I am a programmer, and C is my main language. The reason why I said that we really don't _need_ C modules is that they're not really necessary. Gentoo does splash images by having you give it a config file and a bunch of static images. You can have it display different images based on which part of the init script/boot you are in. It works very well, doesn't lag, and has no C modules.

It's not necessary (depending on what you're trying to do, of course) and image-blitting, lag-free solutions exist, but if you want to write your own splash program, feel free to do so and include C modules. The reason why I kept trying to push the discussion back to images was because we were trying to (AFAICT) discuss the possibility of customizing the boot screen within the standard Angstrom distro - this would involve modifying psplash. IIRC, it can display a loading bar and a static image. I was trying to keep us on track with discussing what types of loading bars/screens/etc. we could make that would work with psplash without having to include different software for splash screens and the like.

EDIT: It would be nice if you didn't demean people and assume that they have no programming knowledge because they disagree with you.

 

[Mithrildor]

The original idea is possible. If you can use bars Im sure you can have a layer over the bar.

 

[dflemstr]

@Vorporeal: I fear that you misunderstood me. I didn't mean that we should implement a completely new splash program
I just thought that the default splash application included in Ångström (PSplash you say? good to know) had support for C plugins, and it thus would be wisest to target the develoment of boot screens towards such a module.
Oh well, I should have researched better, I guess

EDIT: I saw what I wrote here:
QUOTE
Now, leave the implementation of the splash animation to the programmers and continue spitting out more ideas (Just don't expect it to be possible to drop a .psd in some folder and just use it as a splash anim.)


...and looking back at it, it really sounded kind of arrogant. I wasn't meaning to include myself among that set of programmers and demean others; I just wanted to end the discussion that had arisen about thinking too much about the splash backend instead of the splash screens themselves. Sorry if you misunderstood me

Now, on with the show...

 

[Creature XL]

It could have two images exactly the same, except the second one has the progress bar full, so you just draw the right amount of the second image each time.

...and then you would have a 2mb big boot screen.
Optimization is very important when doing this kind of thing. And, if it is possible with C code, why not do it in C code?

Yeah of c ourse 2Mb. Better check your math

800*480*2*2 (for 16 bit image), 768kB for 8 bit image.

But, you don#t have to use the whole image. Just the "pandora "text changes whichis harldy 1/4th of the image.
On the otherhand it should be very easy (if you can use C code) to make a simple color calculation for the columns which should be colored in a different color.
When I think about it, it should be enuff just to calculate one (or zero columns) column each frame.
As long as we talk about a simple image where only one solid color gets changed to another solid color.

The easiest idea (do avoid if-statements) would be like this:
assume 24bit-RGB for simplicities sake, so 0xff0000 is RED

If you take 0xf00000) as the color for the "right" part and 0xff0000 for the "left" part your bitmap would be 0xf00000 in the whole "pandora" text. All other colors on the screen HAVE TO BE 0x00XXXX!

Now your routine gets called with "75%". you calculate that you have to paint one column (the others were already painted with the last calls) of your image, then you just do

CODE

for ( int y = Y_OFF; y < Y_OFF + P_HEIGHT, ++y)
bitmap[x + y*800] |= (bitmap[x + y*800] & 0xf00000) >> 4;



Considering the "shift for free" on ARM it should be fast.
With a good choice of bits to use you can find some nice colors I hope

I didn't test it, but it should work. If this idea does not work, then sorry for taking your time

PS:
for those of you who don't want to think too long about this idea:
The gist is, that all colors which should not be changed (like the background or the shadows will not be affected by the calculations, so you don't have to insert IFs which stall the pipeline and make it slow. You can even unrole the loop cause it is always an constant height per image.

 

[dflemstr]

I'd rather use the LSB on the color (which would be #000001; I know this is a big endian arch, but in this case it shouldn't matter since the color gets encoded)
Or why not just use a bitmask? Would use something like 1kb of extra RAM, but we can afford that.

Anyways, we'll stay away from complex C modules, at least in the beginning, since the possibility of using just a plain image is there, apparently.
PSplash, as it turned out, DOES support C "modules" (and nothing else, there's just a script to convert images) so this WILL be the preferred way of doing things for more advanced boot screens.

 

[(naw)mcx]

(on a slightly less technical note, my friend is making a flash version of what it might look like)

 

[(naw)mcx]

I had a crack of it, it looks rather lovely, if I do say so my self
CODE
http://megaswf.com/view/bc1f4dd32d684c2c0de7147fffd3c8d8.html

 

[Trip]

I had a crack of it, it looks rather lovely, if I do say so my self
http://megaswf.com/view/bc1f4dd32d684c2c0d...7fffd3c8d8.html


Looks good and shouldn't be too hard to implement for some one that knows how.

I think the loading meter works kinda the same way that the status bars in a Rockbox theme does. I've managed to change one of them before, but it took me ages since I didn't know any code and I probably just got lucky in the end :lol:

 

[PSyMastR]

Looks nice, but the tan reminds me too much of ubuntu