[mynci]

ok, i'm getting closer, but maybe someone here can help me.

i'm not getting the depth of stuff rendered properly and its driving me mad :)

if you take a look at this screenshot:
screwed up vis

you can see what i mean.

its just drawing on top of whats there regardless of 3d position. stuff to the right of a row is drawn on whats already been drawn on the left and when drawing a row behind the front one it appears on top of it!

i'm using the spectrum/fountain code as a base and i've checked my winding of verticies. checked the culling and that seems fine and tried with/without z buffer enabled.

any ideas?

[Gamester17]

@mynci, suggest you post new separate topic in the development frorom to get more attention, (as this thread is for vis interface dev only)

[mynci]

@mynci, suggest you post new separate topic in the development frorom to get more attention, (as this thread is for vis interface dev only)

this was fixed in the main xbmc cvs a while back, but thanks anyway

don't think i'm gonna have my vis doing everything i want by the weekend, but i'll have something ready.

[nmrs]

there's been discussion in the g-force thread about adding fps to g-force. i was thinking that rather than having questor add framerate to g-force, it should be added to xbmc itself, that way all vis's could benefit from it. a bool could just be added to vis_info struct:

struct vis_info
{
            bool bwantsfreq;
            int isyncdelay;
            bool bdisplayframerate;
};

that way vis's themselves could still determine whether it was being shown (probably from setting in xml), but all vis maker's wouldn't have to duplicate this code.

[Butcher]

fps calculations aren't all the complicated really. it would be pretty easy to have the app overlay a fps count on the screen while running the vis, but that would mean the vis author has no control over positioning and style of it.

another alternative is to have the app calculate the frame rate and pass the number into the vis once per frame (this can be done with the audio data update which is now once per frame). it can also pass in sync delay here (as this can vary quite a lot if playing an internet stream).

edit: basicaly what i'm proposing is changing

void audiodata(short* paudiodata, int iaudiodatalength, float *pfreqdata, int ifreqdatalength)

to

void audiodata(short* paudiodata, int iaudiodatalength, float *pfreqdata, int ifreqdatalength, float fsyncdelay, float ffps)

[pike]

i say screw the authors in this case

this sounds like a nice osd toggable option, for now, since we dont have a osd, it could be toggable with title or something

[pike]

i just realized something. it would be alot more logical if this fps display inherited the info button, and the old popping up info was on title

[nmrs]

i sort of agree with pike--i think it should be part of the audio osd. it also think it would be nice to update the audio osd to display artist and song next to the album image. something along the lines of what is shown in the second image from the g-force screen shots:

http://soundspectrum.com/g-force/screenshots.html

i think centralizing the osd as much as possible will give a more cohesive look to xbmc--if all vis makers have to come up with their own osd metaphors, things could get messy.

[MrC]

visualistion interface now updated to pass in the pixel ratio of the current screen resolution on visualisation creation.

void (__cdecl* create)(lpdirect3ddevice8 pd3ddevice, int iposx, int iposy, int iwidth, int iheight, const char* szvisualisation, float pixelratio);

[snq]

i'm having a problem while trying to make a vis for xbmc..
drawindexedprimitive somehow doesn't work. i tested the same code on windows and in a standalone xbe and both work fine, but when ran as an xbmc vis i get a blank screen.
no crashes and the framerate is 50 fps. the regular drawprimitive worked, but i need drawindexedprimitive. it can't be a memory issue because the index buffer is only 12 bytes large

any ideas what could be causing this?
could it be some renderstate that i'm forgetting?

all clues are welcome, i've been trying to figure it out for about a day but i can't get it to work


edit: i solved it for now using drawindexedprimitiveup. i guess there's not much use for vertex- and index buffers anyway on xbox.. now i got some rewriting to do, all my existing code uses them

[snq]

here's a first screenie of my vis if anyone's interested.. just a little test. i'm still working on porting my existing 3d engine but most of the stuff seems to be working now so soon i can start on the real stuff!
http://img401.imageshack.us/img401/2905/...0014mz.jpg

[jiz_king]

i'm looking forwared to seeing what you can do.

looks good from what we can see so far.

j.

[pike]

fullscreen screenshot would be nice :o

[snq]

here's a fullscreen screenie then.. really not that much to be seen yet
http://img426.imageshack.us/img426/1880/...0131oh.jpg

i'm having some trouble getting the audio data to work with my existing fft code (which was originally written for a winamp2 plugin).
so i have some questions about the function audiodata(short* paudiodata, int iaudiodatalength, float *pfreqdata, int ifreqdatalength)
how is the format of paudiodata? is it 1 short left channel, 1 short right channel, 1 left, 1 right, etc.. or iaudiodatalength/2 times left and then iaudiodatalength/2 times right?
how often is it called? once for every call to render(), or when audio data becomes available? how often is that in that case, and about how big is iaudiodatalength usually?
there, lots of questions

(ps i have no idea how to output debug strings or i would've figured it out myself )

[pike]

i would love to help you. you know that sources for all viz'es are in cvs ? http://cvs.sourceforge.net/viewcvs.py/xb...lisations/

maybe some clues there ?