farbrausch demo tools open source
category: code [glöplog]
player x64 compiling did not work. if i use a werkkzeug 64bit, compiling more than 4 gig are not working. if i do the commandline for packing, it writes out of mem. i have 8 gig ram
patches welcome.
did the player64 ever work?
patches welcome.
werkkzeug 64-bit has been in intensive production use over a period of several years. so in general, 64-bit works.
i don't think we've ever tried building anything that uses wz4frlib as 64-bit target, though.
i don't think we've ever tried building anything that uses wz4frlib as 64-bit target, though.
patches welcome.
Quote:
_sauron_, try to set ProjectSiteId in the Document Properties.how to switch on the wz4player "share!" option?
Actually, look into the player's main.cpp where ProjectSiteId is used, and change the URL to something that's not our FR webpage. You probably want that. :)
thx for help you both ... i set
ProjectId = 0;
SiteId = 0;
to 5, but nothing happened to the player.. i just want to show the shares like in fr 63 prod.
ProjectId = 0;
SiteId = 0;
to 5, but nothing happened to the player.. i just want to show the shares like in fr 63 prod.
hm.. there is no handle called "ProjectSiteId " any ideas to set share options on?
you gotta set it in wz4s demo options and it's checked in the player. there. where you have to change
Code:
if (opt.SiteId)
{
selsetup.Sites[0].IconInt=100;
selsetup.Sites[0].URL.PrintF(L"http://www.farbrausch.com/prod.py?which=%d",opt.SiteId);
static const sChar *siteids[]={L"birdcage",L"cakefuck",L"diespace",L"rigged",L"stumbleupon"};
for (sInt i=0; i<sCOUNTOF(siteids); i++)
{
selsetup.Sites[i+1].IconInt=200+i;
selsetup.Sites[i+1].URL.PrintF(L"http://www.learntocode.com/share.py?which=%d&site=%s",opt.SiteId,siteids[i]);
}
}
"cakefuck"?
should have called it fakebook or lamebook or what? them industry fuckin' you privacy. while having a coffee break with cake. sure tho could have called the other "flyspace" or something, cause i still see alotta music in there. happy now? :D
is the drug you're taking on wikipedia?
lol. yeah... sure... i must be on drugs if i refuse to use all those fine social networks. sure. thanks for judging me. ;)
back to topic...
back to topic...
back to topic?
patches welcome!
patches welcome!
patches welcome!
fine sauron, help me port libv2 to x64. and C++.
mudlord, how's that going btw?
mudlord, why you want to port v2 player to c++? This library is written in assembler for most performance and small size. BTW, player and DXsound output code is written in c++.
easier to maintain / fix ?
There is several design flaws with the library. ie: lack of thread safety.
just cause i'm a not a good multithreader. why is it not thread safe? it usually only uses one initialisation and ds locks and renders in a single threaded loop. does the thread affinity mask not handle things like that?
v2mplayer.cpp looks fine.
synth.asm seems to share common structures between instances, and crashes seem to occur directly in there.
This is not a problem when running a demo. It is a problem when you are using libv2 to decode V2M files in audio players that rely on multiple instances of the V2 synth (ie: foobar2000) for different operations like conversions/decoding/ReplayGain scanning, all at the same time.
synth.asm seems to share common structures between instances, and crashes seem to occur directly in there.
This is not a problem when running a demo. It is a problem when you are using libv2 to decode V2M files in audio players that rely on multiple instances of the V2 synth (ie: foobar2000) for different operations like conversions/decoding/ReplayGain scanning, all at the same time.