[emphatic] Wish List

Hijack doesn't attempt to deal with handing the screen to the apps right now -- can the app instead simply grab the screen at startup? Oh, wait.. we don't have an ioctl for that..

Gimme a few more minutes..

Okay, Hijack v405 is out.

The only change is a new untested ioctl() call that apps can use to immediately takeover the display/buttons, as if they'd just been selected from a menu, but without the need to bind to the menu (in fact, crazy things could happen if they DID bind to the menu first.. or not.. haven't thought about it much).
Code:

---

if (0 == ioctl(fd, EMPEG_HIJACK_TAKEOVER, NULL)) {
      // success, we now own the display
} else {
      // probably got EINTR, or some other error
}

---

The practical use of this new ioctl is in combination with the v403 ;@MENUEXEC feature, so that ;@MENUEXEC can be used to select/activate the app from scratch, and the app then invokes EMPEG_HIJACK_TAKEOVER to foreground itself on startup.

If another app already has the display (in use), then EMPEG_HIJACK_TAKEOVER will block until the first app releases the display.

Cheers

Hijack v406 will be out Real Soon Now, fixing a slight logic error on the new TAKEOVER ioctl.

-ml

While you're in a giving mood, care to give me an ioctl which blocks until the player's finished starting up? Or can you detect that? (By start up, I mean it's gone through the "reading databases" and all that stuff.)

Problem is, my app starts up and calls TAKEOVER (which works great in v406, BTW) and wants to change info modes, but the player isn't ready to accept button presses yet. My other alternative is sleeping for some period of time, but that's hokey.

Well, internally Hijack has a concept of "player started", but I don't recall how it treats poweron->standby.

I'll stick a waitq and ioctl onto it for you, and you can play with it.

EMPEG_HIJACK_WAIT_FOR_PLAYER

Cheers

Another new ioctl() call for use from apps. This one pauses the app until the player is deemed "started" by Hijack. No effect if player was already up and running.

-ml

Okay. v407 is now up on the server.

-ml

WAIT_FOR_PLAYER works very well.

I'm a little confused about using TAKEOVER though. It works, but if I quit my app (call WAITMENU with NULL) my program exits, but the screen is frozen (i.e. the player buffer doesn't go back to the foreground.) I think I understand why (I didn't originally call WAITMENU to bind to the menu to begin with.) Any way around this? Maybe some operation that's the inverse of TAKEOVER and explicitly hands control back to the player or the hijack menu? I guess my problem is I'd like to TAKEOVER in the beginning, but I'd like to give the user the option to close my app temporarily (leaving it running and available in the Hijack menu) which I presently accomplish using the WAITMENU ioctl. Can these two play nicely together?

I think I can fix TAKEOVER so that a WAITMENU(NULL) works correctly -- v408 shortly.

Fixed.

Any way to fix it so that I can start with TAKEOVER but then bind to the menu? i.e. logic like this (apologies for slacker pseudocode syntax)

Code:

---

WAIT_FOR_PLAYER
TAKEOVER

while (!quit)
{
  while (!hide)
  {
    


  }
  WAITMENU(menulabels)  // to bind to the hijack menu
} 
WAITMENU(NULL)  // to quit

---

Just do a WAITMENU(NULL) before the first WAITMENU(non-NULL).

-ml

Couple of unrelated wishes...

------ Emphatic wish: -------

Have some sort of a file, most likely XML, which you do NOT supply in the emphatic distribution, which can contain overrides to the current XML file. In this file, I could place my own personal customizations that are above and beyond the default settings supplied with the "factory" distribution.

For instance, if I want to customize one of the visual modes, or change the exit_visual and exit_info settings, currently I must do so by editing the main "emphatic.xml" file directly.

This means that if you do a new release of emphatic with new visual modes in the main XML file, then I must merge my changes into your new file before placing it on the player.

But if I had my own override file, and it contained ONLY the things I wanted to be different from your XML file, then updates of the original XML wouldn't be a pain to install.

Please forgive me if this feature already exists and I just missed it.


------ LrcDB wish: --------

A link I can click on that would let me see a single list containing all the songs I have submitted.

Again, if this exists already and I just missed it, my apologies.

Oh, Tony, while watching a lyric scroll by, I had an epiphany about the CPU usage with the burnin feature.

Are you recalculating the burnin pixels for every frame?

The text doesn't change nearly as many times per second as the visual does. If the burnin pixels and/or text were somehow stored in a third buffer (perhaps using an intermediate pixel value as the value for transparancy), and just the buffer-overlay-onto-background operation happened every frame, then you'd only need to rewrite the buffer when the foreground layer changed (say, when the user presses a button, or when the time index counter rolls over and you draw a time, etc.).

This means the burnin code would eat a lot less CPU. It would still make a stutter when it *did* run, it just wouldn't happen every frame any more.

Is it possible to mark a track and apply a value other than marked? Similar to how the song rating feature works,select mark and then choose 1,2,3 a,b,c or whatever to mean different things.Such as A=lyric errors, B=encoding errors,C=delete track

Also the ability to see the new mark meaning in emplode or jemplode

Hmm...You could try the following;

Create 2 copies of the text buffer.
Shift copy A 1 pixel right and add it pixelwise to B.
A down and add to B,
A Left, add to B.
A Left, add to B
A Up, add to B
A Up, add to B
A Right, add to B
A Right, add to B.

8 * 4096 = 32768 integer additions per screen (fast). Anything non-zero in B is to be burned, so that adds 4096 simple compares per screen.

Hmm. Quick gimp mock up, achieved by manually following the above process with multiple offset layers in 'lighten' mode.



Note that I inverted the original to show the contrast. In reality the mask ends up inverted against the background image and the original stays non-inverted. I suppose I could have imported a visual background and done it right, but I couldn't be bothered.

I could swear I'd thought of doing that and then something in my head told me it wouldn't work, that somehow it wouldn't do the same kind of outline. Either that or it some how ended up using the same amount of CPU. But from what you're showing there, it looks like it works, the outlines look like the exact same thing, and from what you're saying, it would theoretically use less CPU. So why had I discounted the idea before? Anyway, that's pretty cool and I hope it's something Tony can use!

By the way: You know you've used bitmap editors too much when you see a screenshot like that, and your brain automatically fillis in the animation of the dotted selection outlines. I kept thinking I saw them move out of my peripheral vision.

Cool. I think I'll try either this or the "save the mask and only update the mask when the foreground changes" idea sometime soon.

Or both.

I've been studying your code and thinking more about the problem.

It may not be quite as straightforward as I originally thought as I had forgotten about the 2 pixels per byte packing.
Code:

---

{

  fy = iy + py;

  fx = ix + px;

  if ( fy < 0 || fy >= EMPEG_SCREEN_ROWS || fx < 0 || fx >= EMPEG_SCREEN_COLS )

    continue;

  if ( px == 0 && py == 0 )

    continue;



  n = 64 * fy + fx / 2;

---

This kills you because you hit it (or its sister) every time until done=1. An immediate obvious improvement would be to shift the "if ( px == 0 && py == 0 )" test up a few lines so that you can avoid the two additions and tortuous bounds test for that pixel. The real killer is the bounds test - it only has any effect for 318 out of 4096 pixels, yet you have to do the 4 comparisons every time.

This is something that I hope my method will avoid. By doing the 8 additions sequentially in turn, each addition could be bounded within the 'for' loops.

However, your algorithm only has to deal with the buffer packing problem once per pixel when you burn the bg buffer, or 4096 times per screen refresh. My solution would require this to be done for every addition...ie in the order of 32768 times. It's not the straightforward addition that I thought it was. You can't bytewise add either as you'd get carry problems between the nibbles.

There may be a way around this...it occurs to me that we only care if a pixel in our temporary buffer is non-zero after all the additions. Whether a nibble is 0x1 or 0xf is irrelevant - we burn the bg buffer for that pixel.
Because of that we may be able to use a bitwise OR instead of addition and actually achieve the same result in half the operations.

In order to shift the fg buffer one pixel left or right still is an issue though. If we could 'rotate with carry bits' across 64 bytes then it would be fairly easy.

I'm beginning to wonder whether unpacking the fg image into a byte per pixel copy might be worth considering to make the math faster.

Or you could just draw the text in black eight times, then in white once. No separate layer, just draw it directly onto the buffer.

I know it's not a generic solution, doesn't allow for certain kinds of interesting combinations, and means that things like the progress bar would have to be special-case coded, but perhaps it would be simplest and fastest.

Hmm. I can't remember how flexible vfdlib is with regards to this. I wonder how fast drawing the text is...

Doesn't it keep an unpacked representation of the display buffer in memory and blats that when you tell it to?

Dumb question here.. I haven't even played with this yet so I apologize if this is something that is painfully obvious:

My database size is "too large" at the moment, and I've been going through all my songs in emplode removing the "Comment" field (and have been toying with the idea of removing Genre) to reduce the size of the database. Since the lyrics are stored in the id3v2 tags, will this cause any issues?

Can I install this on top of 2.00final and select when to boot into it via HiJack or does it always run after it's installed?