View Full Version : G-Force vis-plugin porting to XBMC, need help plz
questor/fused
2004-03-04, 23:27
okay, with the great help from pike i've got a compiled version of my g-force-port compiled with the vs.net2003. but when i try to load it in xbmc i get unresolved symbols!
unable to resolve kernel32.dll setendoffile
unable to resolve kernel32.dll virtualprotect
unable to resolve kernel32.dll lcmapstringw
unable to resolve kernel32.dll lcmapstringa
unable to resolve kernel32.dll writefile
unable to resolve kernel32.dll rtlunwind
unable to resolve kernel32.dll getcommandlinea
unable to resolve kernel32.dll deletefilea
unable to resolve kernel32.dll setlasterror
unable to resolve kernel32.dll heapdestroy
unable to resolve kernel32.dll heapcreate
unable to resolve kernel32.dll virtualfree
unable to resolve kernel32.dll virtualalloc
unable to resolve kernel32.dll heaprealloc
unable to resolve kernel32.dll isbadwriteptr
unable to resolve kernel32.dll sethandlecount
unable to resolve kernel32.dll getstdhandle
unable to resolve kernel32.dll getfiletype
unable to resolve kernel32.dll getstartupinfoa
unable to resolve kernel32.dll exitprocess
unable to resolve kernel32.dll terminateprocess
unable to resolve kernel32.dll getcurrentprocess
unable to resolve kernel32.dll getmodulefilenamea
unable to resolve kernel32.dll freeenvironmentstringsa
unable to resolve kernel32.dll getenvironmentstrings
unable to resolve kernel32.dll freeenvironmentstringsw
unable to resolve kernel32.dll widechartomultibyte
unable to resolve kernel32.dll getenvironmentstringsw
unable to resolve kernel32.dll unhandledexceptionfilter
unable to resolve kernel32.dll heapsize
unable to resolve kernel32.dll getstringtypea
unable to resolve kernel32.dll multibytetowidechar
unable to resolve kernel32.dll getstringtypew
unable to resolve kernel32.dll getcpinfo
unable to resolve kernel32.dll getlocaleinfoa
unable to resolve kernel32.dll getacp
unable to resolve kernel32.dll getoemcp
unable to resolve kernel32.dll isbadreadptr
unable to resolve kernel32.dll isbadcodeptr
unable to resolve kernel32.dll setstdhandle
unable to resolve kernel32.dll virtualquery
unable to resolve kernel32.dll flushfilebuffers
unable to resolve kernel32.dll raiseexception
they're not in the dll-loader included, so no chance to get the plugin running :) is there a special trick with compiling; where does the symbols come from? i've copied the vs-goom-project-file and modified it to make it compile gforce instead.
some functions i don't know why they are needed (example lcmapstringw). perhaps i have to modify the code a little bit more :/
any suggestions?
most of those should be loadable, the xbox certainly has most of those functions, maybe some fixing required for the dll loader.
Gamester17
2004-03-29, 15:05
i've converted the g-force-plugin (http://www.55ware.com/g-force/index.html) to the media-player (http://sourceforge.net/tracker/index.php?func=detail&aid=907028&group_id=64793&atid=508680)! i can't convert it to the center, because i only have the old visual-studio *:( *perhaps in the near time i can get hold of the new one, but so long i have no chance to get it working. beside there are some unresolved entrys in kernel32 (and perhaps in msvcr). so there is some work left.
it's working great with all the scripts from the new version
hi questor/fused, how are you getting along porting gforce from xbmp (http://sourceforge.net/tracker/index.php?func=detail&aid=907028&group_id=64793&atid=508680) to a xbmc dll? ps! yes you do need vs.net 7.1 (2003).
please let us all know if you run into any problems and need our assistanse, we all love to see it make the visualization competition (http://www.xboxmediaplayer.de/cgi-bin/forums/ikonboard.pl?act=st;f=1;t=1077)
questor/fused
2004-03-29, 20:11
okay, i've finally got vs.net2003 and could compile the plugin. but there is a little problem left :(
the plugin needs the dll-functions "??2@yapaxi@z" (malloc) and "??3@yaxpax@z" (free). in the dllloader are these functions defined for the msvcrt.h, but not for the msvcr71.h. and the plugin imports the functions from the 7.1runtime...
i've tried simply including the functions in 7.1 like they are included in the msvcrt, but that doesn't work even with the "normal" viz-plugins. don't know why?!? i always get a access-violation.
can anyone help me with this one?
hmm malloc and free should be imported as _malloc and _free. are you sure they aren't new and delete?
questor/fused
2004-03-30, 15:06
sorry, they are in fact new/delete :angry:
what i find strange: when i include them into the 7.1 runtime, the other plugins crash after one time activating/deactivating them, too. perhaps i'm doing something terrible wrong. including it generates a bufferover- or underrun...
doesn't use the other plugins new/delete or why doesn't they have the import-problem?
i think goom has this issue - it doesn't dealloc a lot of memory (~3mb). new is a layer on top of malloc/free though so for goom i just hooked malloc/free and clean up for it.
questor/fused
2004-03-30, 19:02
yes, goom uses malloc/free and not new/delete!
what have i done:
downloaded sources this weekend and compiled and everything is ok.
added the following code to msvcr71.h (in core\dllloader):
#ifdef global_scope
extern "c" void dllmalloc(void);
#else
exp2dll* msvcr71_exp119 = new exp2dll("msvcr71.dll", "??2@yapaxi@z", (unsigned long)dllmalloc);
#endif
#ifdef global_scope
extern "c" void dllfree(void);
#else
exp2dll* msvcr71_exp120 = new exp2dll("msvcr71.dll", "??3@yaxpax@z", (unsigned long)dllfree);
#endif
now complete recompile, start mp3-playback with spectrum-viz (pressed blue button to start viz). everything is ok so far. but then i press the blue button again to change to the mp3-list back and i get this error
assertion failed:
_asserte(_block_type_is_valid(phead->nblockuse));
(from dbgdel.cpp)
i think there is a memover- or underrun, but don't now where/why?!?
perhaps now it's clearer to reproduce/understand what's going on....
the import "??2@yapaxi@z" and "??3@yaxpax@z" are in the msvcrt.h defined, too. but that should be no problem at all....
i think the memleak is not the problem at all, but the internal management from dllmalloc/dlldelete. does it handle new and new[]? is there a difference between them? (there should be a difference between them; red it here: http://weblogs.asp.net/oldnewthing/archive/2004/02/04/67384.aspx )
thanx for your help!
questor/fused
2004-04-04, 15:18
ok, found the problem:
in dll.cpp are leaks detected and delete:
for (std::map<unsigned, unsigned>::iterator p = it->alloclist.begin(); p != it->alloclist.end(); ++p)
{
total += p->second;
// free((void*)p->first);
}
i think, it's because new[] can't be delete with "free". disabeling the "free" fixed the crash (but not the memleak http://www.xboxmediaplayer.de/forums/non-cgi/emoticons/tounge.gif )
edit: hm. that doesn't make much sense. both uses malloc...
um doing that is a bad idea as it makes goom leak 3mb a time... http://www.xboxmediaplayer.de/forums/non-cgi/emoticons/tounge.gif
zilvershadow
2004-04-10, 19:08
wow g-force is awsome! i love it!
you guys are the best!
any chance for the g-force visualisation to support album art and artist and song name like in this picture?
http://musicalcortex.com/g-force/screenshots/s26.jpg
this picture came from the g-force homepage and is a feature of the pc version.
amazing work on the visualisation. there is no doubt in my mind this should be the default plugin used.
look forward to any updates.
i agree g-force is amazing, but i don't think it's g-force's place to do album art. this is already in [hit the white button or info to bring it up], and if you'd like it to stay onscreen as i would, post in this thread: http://www.xboxmediaplayer.de/cgi-bin....t=2633 (http://www.xboxmediaplayer.de/cgi-bin/forums/ikonboard.pl?act=st;f=4;t=2633) and maybe nrms + one of the devs will come to our rescue.
zilvershadow
2004-04-12, 18:38
is g-force compatible with whitecap configs? there are a lot similarities with whitecap. when g-force isn't compatible it wouldn't be difficult to port it to xbox. whitecap has some nice effects that i would like to see on my tv ;-p
thanks
questor/fused
2004-04-13, 12:43
don't think that whitecap-configs work. it's a completly different rendering-method (whitecap uses lines, gforce waveforms and flowfields)
perhaps it could be added to gforce on xbox, but first gforce should be optimised to get more fps.
i just registered on the forum to thank you for the great job on porting g-force to xmbc, it looks really amazing!
why do you leave the default res on 320x288? i'm running 720x576 here on my pal 16:9 and it plays super-smooth :-)
thanks again!
it's @ that resolution because when it was added to cvs it wasn't as fluent in 720x576. (perhaps 10fps)
yesterday a bug was solved which doubled the speed.
i dont think it runs in full speed at this high resolution either, i estimate ~20fps, smooth would be 25 or 30 fps.
strange thing is: 640x480 is not smooth at all
but 720x576 is very smooth
is there a way to see the fps?
not yet, but i believe questor is working on that <hint, hint>
silentyl
2004-04-15, 05:25
how are you guys changing the resolution from 320x288 to 720x576 ?
Gamester17
2004-04-15, 12:59
remember though that some audio codecs take much more cpu time than others to decode so it's good to keep default resolution low http://www.xboxmediaplayer.de/forums/non-cgi/emoticons/wink.gif
questor/fused
2004-04-15, 14:52
fps-display is in work :)
and i want to optimize the plugin, but don't know how fast i can get the little thingy. startup is very slow because the compilation of the script is not very optimised and reserves many small memoryblocks. a memorypool should speed it up.... when i have some time...
remember though that some audio codecs take much more cpu time than others to decode so it's good to keep default resolution low http://www.xboxmediaplayer.de/forums/non-cgi/emoticons/wink.gif
also if you have hq resampling on that sucks quite a bit of cpu.
maybe 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.
(i'm cross posting this in the visualization plug-in interface forum)