Llama's and Intuition's Techie Thread - Page 5

intuitionsys · 03-31-2006, 03:09 PM

I use KDevelop for linux projects as well. The only really annoying thing it does is collapse your class view every time you compile, but that's a minor pebble in my shoe. It does, as one might say, rock

TheLlama · 04-05-2006, 12:45 PM

I just checked out KDevelop. It is very nice. I don't like all the bloat with automake though. I want to try it out some more, is there a VIM plugin that makes the integrated text editor act as VI? I still think that for any programming environment to be useful it has to have advanced text editing like the features included in VI or emacs. I usually use VisVim inside of VisualStudio when I have to do work on Windows.

/Tangent

intuitionsys · 04-05-2006, 07:08 PM

I don't know of one but I never bothered searching either since I don't like VI anyway. There are some nice things about the editor in VS 2003 I like that would make life a bit easier in the default KDevelop editor but there are always new goodies with every new (major) release.

On a happier note I'm very very close to cracking the Xine nut finally. I've tried umpteen variations, some involving very complicated memory access, but it looks like the round-robin approach using a modified Xine driver fits the bill the best. I'm using a close callback in FMOD to signal the load of the next data file in the stream sequence (but haven't actually written the code for it; hopefully tomorrow). Tests I did with a simple test app (not in Silverwolf) worked very very well so that's the method I'm going to stick with even if it does seem a tad hokey

I'll post the code this week or possibly next on swaesbb depending on how much life gets in the way...

TheLlama · 04-05-2006, 08:52 PM

Quote: Originally Posted by intuitionsys

I'm using a close callback in FMOD to signal the load of the next data file in the stream sequence (but haven't actually written the code for it; hopefully tomorrow). Tests I did with a simple test app (not in Silverwolf) worked very very well so that's the method I'm going to stick with even if it does seem a tad hokey

I'll post the code this week or possibly next on swaesbb depending on how much life gets in the way...

Thats cool, I'm using basically the same technique to start playing the next song. But I actually have two Sounds. One for the current song and one for the next song, this lets the next song prebuffer or at least get the song info. Now skipping to the next track is a bit faster and I _could_ have a little "Next Song Info" notification come up as the current song is ending. Plus, I can easily implement crossfading with this technique.

I do this by having a current and next pointer. When the song changes I stop the current sound and destroy it. Then I set the current pointer to the next pointer.Then the new current song can be started. Finally, I create a new sound for the next pointer.

(So sort of like round robin, but simplified since there are only two items)

I hope to have the source for my AudioSystem, Player, and Library released soon.

intuitionsys · 04-10-2006, 04:20 PM

I'm having trouble getting FMOD to use my callbacks and it's really (*&$#ing me off

Have you run into any problems in that area? I've tried using setFileSystem() and attachFileSystem() and neither one appear to do anything. I'm sure it's something retarded I'm doing but I thought I'd rant here real quick if anybody has any suggestions...

TheLlama · 04-10-2006, 07:48 PM

I've used FMOD callbacks before, but not filesystem callbacks. Do you need to enable it somehow?

intuitionsys · 04-10-2006, 07:59 PM

I just found a workaround that equates to the same thing. I'm using a thread to check the playing status rather than updating the status in a timer that fires the callback.

I just got it working so the code won't be up on swaesbb for probably a day or two while I fine tune things. I'll post the xine audio driver mods there at the same time...

Uggh finally!

intuitionsys · 04-11-2006, 10:56 PM

Holy moly! This makes no sense but it works; I've verified it several times - I ran into it totally by accident:

keep the system, channel and sound pointers app global, then call Xine with a null audio driver, but keep updating the spectrum info - and it does. Why does this work? I haven't a clue. I need to do more testing to make sure I'm not blowing smoke though since this seems a bit too good to be true.

TheLlama · 04-11-2006, 11:03 PM

Quote: Originally Posted by intuitionsys

Holy moly! This makes no sense but it works; I've verified it several times - I ran into it totally by accident:

keep the system, channel and sound pointers app global, then call Xine with a null audio driver, but keep updating the spectrum info - and it does. Why does this work? I haven't a clue. I need to do more testing to make sure I'm not blowing smoke though since this seems a bit too good to be true.

Perhaps FMOD reads the spectrum and waveform data off of ALSA and not FMOD's internal buffers. That would be really cool.

TheLlama · 04-23-2006, 11:35 PM

Ugh... I've been struggling to get Savage 4 drivers working right on the unit. I need video for when I take the box inside. I had Framebuffer console running with normal vesa-tng drivers. Everything was working fine except nothing was output to the LCD. The chip has CRT and LCD outputs. The LCD output is hooked to a converter board which outputs Composite video and S-Video. So, my guess is nothing was running to the converter.

I found a program, s3switch, that is supposed to enable/disable the various outputs. CRT and LCD were already enabled but I tried enabling only LCD, and my monitor lost signal but nothing showed up on the TV. Enabling both makes the monitor run at a lower refresh rate, I guess to match what the LCD output uses. When I enable only CRT the monitor goes to my normal refresh rate. I can tell the refresh rates are changing because CRT causes the screen to be drawn to my configuration and BOTH causes the screen to draw distorted.

I wonder what is wrong... I hope it is just this converter and a new one will fix the problem. I was really hoping for TV-out.

intuitionsys · 04-25-2006, 02:27 PM

Well as for FMOD doing its voodoo with Xine I haven't been able to reproduce what it was doing so I'll just chalk it up to "whatever" and move on. I had Xine going through FMOD with a ring buffer but it still had clicks between buffers that couldn't be completely eliminated, so I'm saying to heck with it for now and will just close the instance and let Xine open the device itself. I won't get spectrum data but I doubt anyone really cares about that while watching a movie anyway.

I wish I could help with your S4 problem but I've never worked with that chipset before. I do know that many chipsets will change the refresh rate for both outputs to 60Hz when composite/s-video out are enabled and there is squat you can do about it.

Oh hey btw have you given your frontend a name yet? I've seen talk around this section about your player but nobody has referred to it by name

Silverwolf 2 is plodding along as I find free time here and there so hopefully the ~3 month timeframe is still accurate. The thing that is really taking time right now is completely re-engineering the skinning and UI. Alot of the backend guts will just be code from 1.x ported to Qt4.

TheLlama · 04-29-2006, 12:44 AM

Quote: Originally Posted by intuitionsys

Well as for FMOD doing its voodoo with Xine I haven't been able to reproduce what it was doing so I'll just chalk it up to "whatever" and move on. I had Xine going through FMOD with a ring buffer but it still had clicks between buffers that couldn't be completely eliminated, so I'm saying to heck with it for now and will just close the instance and let Xine open the device itself. I won't get spectrum data but I doubt anyone really cares about that while watching a movie anyway.

I wish I could help with your S4 problem but I've never worked with that chipset before. I do know that many chipsets will change the refresh rate for both outputs to 60Hz when composite/s-video out are enabled and there is squat you can do about it.

Oh hey btw have you given your frontend a name yet? I've seen talk around this section about your player but nobody has referred to it by name

Silverwolf 2 is plodding along as I find free time here and there so hopefully the ~3 month timeframe is still accurate. The thing that is really taking time right now is completely re-engineering the skinning and UI. Alot of the backend guts will just be code from 1.x ported to Qt4.

The player, for lack of a better name, is called LlamaBox. In regards to the S4, I pointed out 60Hz because that is a good thing. If that switcher changes it to 60Hz then something is right. Anyways, a BIOS flash fixed the problem.

As far as Qt goes.... It is the reason why I wrote my own toolkit. Speaking of that: I just spent today writing a really nice line drawing algorithm. It is based off bresenham's algorithm, but it draws lines with various weight and cap styles. This is needed on my VFD panel where there is no API for drawing primitives. (I've been limited to 1-pixel wide lines on this device until now).

But, The toolkit is coming along nicely. I added selection to the listview widget and I'm in the process of adding a TreeView. I have one huge stumbling block ahead: adding the theming engine. I must decide where to draw the line between the widget level and theme level.

Have you enjoyed using Qt's Styles? Are you making your own QStyle or are you just making your own widgets? When you make your own widgets, do you use the primitives provided by QStyle or do you just do it all by hand? This is the kind of experience I need to decide where to draw this line.

This line must lie somewhere between: "The style draws every widget, the widgets do not draw themselves" to "There is no Style".

The first method has two obvious disadvantages: Custom widgets must be used with a Style that supports them. Derived widgets cause a problem and there isn't any code reusability. The second method doesn't even provide Styles.

So, the answer is some place in the middle, where the Style provides primitives like borders, glyphs, fills, etc.. The hard part is quantifying all of these elements and finding a reasonable granularity.

Oh yeah, and I need to write this kernel module for the HQCT Radio.

EDIT: If you post or read information on this thread that you believe is important or critical then please let me know so I can add it the the first post. Might as well do this right. So, let me know -- even if you just read something from this thread and it helped you out.

EDIT, PART II: If you think of a name better then LlamaBox (there is undoubtably one) the let me know. It doesn't have to relate to anything -- just sound cool. But please PM it to me, or I guess I could start a thread. Now I am just rambling.

intuitionsys · 04-30-2006, 11:49 PM

Quote: Originally Posted by TheLlama

The player, for lack of a better name, is called LlamaBox.

Well... it doesn't actually drip off your tongue does it?

I'm sure someone out there has a killer name...

Quote: Originally Posted by TheLlama

In regards to the S4, I pointed out 60Hz because that is a good thing. If that switcher changes it to 60Hz then something is right. Anyways, a BIOS flash fixed the problem.

Cool. Done and done...

Quote: Originally Posted by TheLlama

Have you enjoyed using Qt's Styles? Are you making your own QStyle or are you just making your own widgets? When you make your own widgets, do you use the primitives provided by QStyle or do you just do it all by hand? This is the kind of experience I need to decide where to draw this line.

So far I've been drawing my own widgets with Qt's painting mechanism; so far they're all based on QFrame. The big one (that I've almost finished) replaces the QListView in all the modules (QDialogs) with a more "car-ish" widget with controls and behaviour so different from QListView itself (or any other Qt widget) that I decided it would be best to do all the primitive drawing myself.
I haven't touched QStyles other than reading through them.

Since all the behaviour and functionality of the widgets I want to use, including how things are displayed, is getting such a massive overhaul, there wasn't much choice but to draw the widgets manually. Qt really speeds things up by providing the primitives and painting engine, as well as some cool transparency effects (that I haven't actually taken advantage of yet but the potential is there nonetheless). In <2.0 I did alot of custom painting and workarounds (see customlvi.cpp for an example if you're curious) to fake the car-ish widgets, but I figured I'm porting alot of code at work to Qt4 so maybe it's time to do the same for Silverwolf and save ALL the mods (including FMOD, no pun intended

) for the big major number jump. I've seen that so many users have so many varied tastes, that QStyles just won't fit the bill anyway, not for something so specific as in-car use. It wouldn't be a bad approach for a desktop player though. Of course that's just one man's opinion...

You should see the skin.conf file for 2.0. It's freaking mental...

I hope once it's ready there are some "skinners" (is that a word or just a principal?) out there who can take advantage of it better than I. Alot of times I go gradient crazy and it just ends up looking gay

strandtc · 05-02-2006, 10:41 AM

No offence.. but I think the reason I havn't actually installed Silverwolf is the skin.. lol. Skinnable would make it much more appealing.

-Chris

intuitionsys · 05-02-2006, 02:01 PM

The current version is skinnable but you'd have to make your own (to your own liking). But if you're going to go through all that trouble I'd wait for 2.0 anyway so I guess it's a moot point

The good news is that almost everything in 2.0 will be sizable and replaceable with your own pixmaps. It just takes too long to draw all the pixmaps and the coding (not that I'm an artist anyway by a longshot

) so the default skin for 2.0 will probably suck too until it a) becomes reasonably popular and b) said users publish their skins.