Menu
▾
▴
opentzt-developers — Code development discussion
You can subscribe to this list here.
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(33) |
Sep
(92) |
Oct
(31) |
Nov
(1) |
Dec
(16) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
(12) |
Feb
(2) |
Mar
(3) |
Apr
(11) |
May
(1) |
Jun
(6) |
Jul
(1) |
Aug
|
Sep
(7) |
Oct
(2) |
Nov
(47) |
Dec
(20) |
| 2006 |
Jan
(40) |
Feb
(27) |
Mar
(24) |
Apr
(8) |
May
(3) |
Jun
(8) |
Jul
(12) |
Aug
(2) |
Sep
|
Oct
|
Nov
(4) |
Dec
(20) |
| 2007 |
Jan
(20) |
Feb
(4) |
Mar
(11) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(7) |
Nov
(28) |
Dec
(28) |
| 2009 |
Jan
(26) |
Feb
(8) |
Mar
(14) |
Apr
(27) |
May
(79) |
Jun
(82) |
Jul
(44) |
Aug
(17) |
Sep
(19) |
Oct
(22) |
Nov
(7) |
Dec
(4) |
| 2010 |
Jan
|
Feb
(1) |
Mar
(34) |
Apr
(56) |
May
(72) |
Jun
(60) |
Jul
(49) |
Aug
(46) |
Sep
(7) |
Oct
(3) |
Nov
(1) |
Dec
|
| 2011 |
Jan
(3) |
Feb
|
Mar
(3) |
Apr
(9) |
May
(8) |
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
(4) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
|
From: Grant M. (Morph) <mo...@mo...> - 2012-01-03 14:11:28
|
LOL me either, I don't even know where to start :P On 4 January 2012 01:06, David Zahn <dc...@gm...> wrote: > Sounds good to me. I've not transferred ownership of a domain before, but > I can't imagine it's that difficult. > > > On Tue, Jan 3, 2012 at 9:00 AM, Grant Muir (Morph) <mo...@mo...>wrote: > >> I'm still paying for the hosting even though its just a redirect these >> days isn't it, prolly easiest if I take the domain aswell. >> >> >> On 4 January 2012 00:57, David Zahn <dc...@gm...> wrote: >> >>> >>> Anybody wanna take over ownership of the domain? >>> >>> My registration is set to expire on 2/2/2012. I can renew it if nobody >>> else wants to, but I'm not really sure it's necessary. >>> >>> Thoughts? >>> >>> Cheers, >>> >>> Dave\Esotic >>> >>> >>> >> >> >> -- >> Grant Muir (Morph) >> _________________________ >> Morph Visual Services >> mo...@mo... >> Ph: +61 (0) 412823786 >> http://morphvisual.com >> > > -- Grant Muir (Morph) _________________________ Morph Visual Services mo...@mo... Ph: +61 (0) 412823786 http://morphvisual.com |
|
From: David Z. <dc...@gm...> - 2012-01-03 14:06:53
|
Sounds good to me. I've not transferred ownership of a domain before, but I can't imagine it's that difficult. On Tue, Jan 3, 2012 at 9:00 AM, Grant Muir (Morph) <mo...@mo...>wrote: > I'm still paying for the hosting even though its just a redirect these > days isn't it, prolly easiest if I take the domain aswell. > > > On 4 January 2012 00:57, David Zahn <dc...@gm...> wrote: > >> >> Anybody wanna take over ownership of the domain? >> >> My registration is set to expire on 2/2/2012. I can renew it if nobody >> else wants to, but I'm not really sure it's necessary. >> >> Thoughts? >> >> Cheers, >> >> Dave\Esotic >> >> >> > > > -- > Grant Muir (Morph) > _________________________ > Morph Visual Services > mo...@mo... > Ph: +61 (0) 412823786 > http://morphvisual.com > |
|
From: Grant M. (Morph) <mo...@mo...> - 2012-01-03 14:01:08
|
I'm still paying for the hosting even though its just a redirect these days isn't it, prolly easiest if I take the domain aswell. On 4 January 2012 00:57, David Zahn <dc...@gm...> wrote: > > Anybody wanna take over ownership of the domain? > > My registration is set to expire on 2/2/2012. I can renew it if nobody > else wants to, but I'm not really sure it's necessary. > > Thoughts? > > Cheers, > > Dave\Esotic > > > -- Grant Muir (Morph) _________________________ Morph Visual Services mo...@mo... Ph: +61 (0) 412823786 http://morphvisual.com |
|
From: David Z. <dc...@gm...> - 2012-01-03 13:57:34
|
Anybody wanna take over ownership of the domain? My registration is set to expire on 2/2/2012. I can renew it if nobody else wants to, but I'm not really sure it's necessary. Thoughts? Cheers, Dave\Esotic |
|
From: Grant M. (Morph) <mo...@mo...> - 2011-06-06 01:32:16
|
Thanks mate, I'll give it some testing this week as I have some downtime on my hands. G On 5 June 2011 07:54, plexus <pl...@op...> wrote: > Hi all, > > even though we decided to change the GUI again, I put out a 3rd beta > release. > The main reason for that is a user who asked for a 720p build. So I > thought, while I'm at it, why not just put out one last beta for the > "1.6 1st edition", for old times sake. ;) > > OK, back to business. > It's as always a "binary only" release. So take care of your existing > stuff (especially the GUI images). > > Since I just forgot to update the change.log (damn it), here's what's new: > The help window, some new switcher icons and a few small bugfixes. > In conclusion: not much. > > For convenience: > http://opentzt.cvs.sourceforge.net/viewvc/opentzt/release/ > > > > ... plexus > > > > ------------------------------------------------------------------------------ > Simplify data backup and recovery for your virtual environment with > vRanger. > Installation's a snap, and flexible recovery options mean your data is > safe, > secure and there when you need it. Discover what all the cheering's about. > Get your free trial download today. > http://p.sf.net/sfu/quest-dev2dev2 > _______________________________________________ > Opentzt-developers mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opentzt-developers > -- Grant Muir (Morph) _________________________ Morph Visual Services mo...@mo... Ph: +61 (0) 412823786 http://morphvisual.com |
|
From: plexus <pl...@op...> - 2011-06-04 21:54:48
|
Hi all, even though we decided to change the GUI again, I put out a 3rd beta release. The main reason for that is a user who asked for a 720p build. So I thought, while I'm at it, why not just put out one last beta for the "1.6 1st edition", for old times sake. ;) OK, back to business. It's as always a "binary only" release. So take care of your existing stuff (especially the GUI images). Since I just forgot to update the change.log (damn it), here's what's new: The help window, some new switcher icons and a few small bugfixes. In conclusion: not much. For convenience: http://opentzt.cvs.sourceforge.net/viewvc/opentzt/release/ ... plexus |
|
From: plexus <pl...@op...> - 2011-05-31 20:29:02
|
Great :) Then I'll rewrite the GUI code. Shouldn't be too hard. During the last rewrite I changed the concept and created many constants, so I basically "just" have to change some XY-coords and adjust some loops. :) But I'd rather make no estimation when it's done since I'm still working on my short film project. And I don't know when I have the next chance to slip in some coding time. ... plexus Am 31.05.2011 05:04, schrieb Grant Muir (Morph): > Yeah loving Test 3 :) > > On 30 May 2011 19:46, James Wise <jam...@gm... > <mailto:jam...@gm...>> wrote: > > Hey Plexus, > > Really like your GUI_test3 concept. > A definite improvement on the current GUI, without a too-radical > change to off put existing users. > > can't see any negatives either, good work. > Let me know when u need some testing :) > > Cheers, > James > > > > > On 25/05/2011 6:25 AM, plexus wrote: > > Hi, > > your 2nd idea is great, the vertical slider is nice :) > Here is a design-test where I adapted the 2nd suggestion and > added all the new stuff. (I can't attach it, because the limit > for mails to the mailing list is 40kB) > > http://opal-city.de/plexus/GUItest_3.jpg > > > As James said: Feel free to comment/critisize/ enhance at will. > > > ... plexus > > > > Am 16.05.2011 15:09, schrieb James Wise: > > Hey all, > > Given i was a bit critical of the new GUI changes plexus > is playing with i thought i would offer some options of my > own, > Hence i have attached 2 ideas that i think represent an > improved version of the GUI. > neither are pixel perfect, but if anyone (plexus?) would > be prepared to turn any of my suggestions into actual > designs i would be happy to do the work required for pixel > perfect and size accurate bmps. > > mockup 1. is just a re-design of the existing interface, > with a larger preview window, and larger images for the layers > > mockup 2. is a mix of existing design and integrates some > of Plexus recent changes, including the redesign of the > Layers so that we can see text names for the effects. > it also has a vertical slider to control the blend between > busses instead of a horizontal slider. > I think the current beta has some extra text bits that > give info about the on/off states of things - which i > like, but haven't included in this mock-up, but there is > still unused space so adding them in shouldn't be too hard. > > anyway i thought since was critical of Plexus last attempt > i should at least offer some of my own. > Feel free to comment/critisize/ enhance at will. > > - James / vj PiedPiper > > > > > > > -- > Grant Muir (Morph) > _________________________ > Morph Visual Services > mo...@mo... <mailto:mo...@mo...> > Ph: +61 (0) 412823786 > http://morphvisual.com |
|
From: Grant M. (Morph) <mo...@mo...> - 2011-05-31 03:05:03
|
Yeah loving Test 3 :) On 30 May 2011 19:46, James Wise <jam...@gm...> wrote: > Hey Plexus, > > Really like your GUI_test3 concept. > A definite improvement on the current GUI, without a too-radical change to > off put existing users. > > can't see any negatives either, good work. > Let me know when u need some testing :) > > Cheers, > James > > > > > On 25/05/2011 6:25 AM, plexus wrote: > >> Hi, >> >> your 2nd idea is great, the vertical slider is nice :) >> Here is a design-test where I adapted the 2nd suggestion and added all the >> new stuff. (I can't attach it, because the limit for mails to the mailing >> list is 40kB) >> >> http://opal-city.de/plexus/GUItest_3.jpg >> >> >> As James said: Feel free to comment/critisize/ enhance at will. >> >> >> ... plexus >> >> >> >> Am 16.05.2011 15:09, schrieb James Wise: >> >>> Hey all, >>> >>> Given i was a bit critical of the new GUI changes plexus is playing with >>> i thought i would offer some options of my own, >>> Hence i have attached 2 ideas that i think represent an improved version >>> of the GUI. >>> neither are pixel perfect, but if anyone (plexus?) would be prepared to >>> turn any of my suggestions into actual designs i would be happy to do the >>> work required for pixel perfect and size accurate bmps. >>> >>> mockup 1. is just a re-design of the existing interface, with a larger >>> preview window, and larger images for the layers >>> >>> mockup 2. is a mix of existing design and integrates some of Plexus >>> recent changes, including the redesign of the Layers so that we can see text >>> names for the effects. >>> it also has a vertical slider to control the blend between busses instead >>> of a horizontal slider. >>> I think the current beta has some extra text bits that give info about >>> the on/off states of things - which i like, but haven't included in this >>> mock-up, but there is still unused space so adding them in shouldn't be too >>> hard. >>> >>> anyway i thought since was critical of Plexus last attempt i should at >>> least offer some of my own. >>> Feel free to comment/critisize/ enhance at will. >>> >>> - James / vj PiedPiper >>> >> >> > -- Grant Muir (Morph) _________________________ Morph Visual Services mo...@mo... Ph: +61 (0) 412823786 http://morphvisual.com |
|
From: James W. <jam...@gm...> - 2011-05-30 09:47:04
|
Hey Plexus,
Really like your GUI_test3 concept.
A definite improvement on the current GUI, without a too-radical change
to off put existing users.
can't see any negatives either, good work.
Let me know when u need some testing :)
Cheers,
James
On 25/05/2011 6:25 AM, plexus wrote:
> Hi,
>
> your 2nd idea is great, the vertical slider is nice :)
> Here is a design-test where I adapted the 2nd suggestion and added all
> the new stuff. (I can't attach it, because the limit for mails to the
> mailing list is 40kB)
>
> http://opal-city.de/plexus/GUItest_3.jpg
>
>
> As James said: Feel free to comment/critisize/ enhance at will.
>
>
> ... plexus
>
>
>
> Am 16.05.2011 15:09, schrieb James Wise:
>> Hey all,
>>
>> Given i was a bit critical of the new GUI changes plexus is playing
>> with i thought i would offer some options of my own,
>> Hence i have attached 2 ideas that i think represent an improved
>> version of the GUI.
>> neither are pixel perfect, but if anyone (plexus?) would be prepared
>> to turn any of my suggestions into actual designs i would be happy to
>> do the work required for pixel perfect and size accurate bmps.
>>
>> mockup 1. is just a re-design of the existing interface, with a
>> larger preview window, and larger images for the layers
>>
>> mockup 2. is a mix of existing design and integrates some of Plexus
>> recent changes, including the redesign of the Layers so that we can
>> see text names for the effects.
>> it also has a vertical slider to control the blend between busses
>> instead of a horizontal slider.
>> I think the current beta has some extra text bits that give info
>> about the on/off states of things - which i like, but haven't
>> included in this mock-up, but there is still unused space so adding
>> them in shouldn't be too hard.
>>
>> anyway i thought since was critical of Plexus last attempt i should
>> at least offer some of my own.
>> Feel free to comment/critisize/ enhance at will.
>>
>> - James / vj PiedPiper
>
|
|
From: plexus <pl...@op...> - 2011-05-24 20:32:07
|
Hi, your 2nd idea is great, the vertical slider is nice :) Here is a design-test where I adapted the 2nd suggestion and added all the new stuff. (I can't attach it, because the limit for mails to the mailing list is 40kB) http://opal-city.de/plexus/GUItest_3.jpg As James said: Feel free to comment/critisize/ enhance at will. ... plexus P.S. @james @morph: don't get confused. I already had the attachment included before I changed the text and sent the mail. > > Am 16.05.2011 15:09, schrieb James Wise: >> Hey all, >> >> Given i was a bit critical of the new GUI changes plexus is playing >> with i thought i would offer some options of my own, >> Hence i have attached 2 ideas that i think represent an improved >> version of the GUI. >> neither are pixel perfect, but if anyone (plexus?) would be prepared >> to turn any of my suggestions into actual designs i would be happy to >> do the work required for pixel perfect and size accurate bmps. >> >> mockup 1. is just a re-design of the existing interface, with a >> larger preview window, and larger images for the layers >> >> mockup 2. is a mix of existing design and integrates some of Plexus >> recent changes, including the redesign of the Layers so that we can >> see text names for the effects. >> it also has a vertical slider to control the blend between busses >> instead of a horizontal slider. >> I think the current beta has some extra text bits that give info >> about the on/off states of things - which i like, but haven't >> included in this mock-up, but there is still unused space so adding >> them in shouldn't be too hard. >> >> anyway i thought since was critical of Plexus last attempt i should >> at least offer some of my own. >> Feel free to comment/critisize/ enhance at will. >> >> - James / vj PiedPiper > |
|
From: James W. <jam...@gm...> - 2011-05-05 13:00:27
|
The best thing to use on iOS would be "AV-Framework", which is about to replace Quicktime on OSX as THE "media layer" for the OS. I am about to get very heavily into this for my work, so hopefully in a few months i will be able to have some insight. it already exists on iOS. I would suggest that on iOS, maybe just 1 or 2 layers per bus? or only 1 of the two Busses, might be more appropriate for such a small/low power device. just my 2 cents! - James PS. for OSX the assembler might not be too hard to port, especially if u keep the same pixel format. Even easier if we port the asm/mmx code to SSE2/3. However on iOS, it would be nigh on impossible? i dont even know if iOS allows such low level access? On 5/05/2011 2:12 AM, plexus wrote: > Hi Morph, > > well, a build from scratch could work, but be aware: openTZT currently > consists of about 33000 lines of code, maybe 4 to 5 percent in > assembler. That's a lot of work. > Is there a multimedia API for iOS ? > > Maybe the best way for you to start is to get as much documentation > about multimedia programming for iOS as possible (especially for > graphics). > Also it's really important to know what video codecs are availabe and > how they perform. You should do some performance tests with plain > video first. > Just to get a feeling for the performance in general. If a codec takes > up most of the CPU power there's no way to make a decent VJ tool. > > Remember: even a modern dual core system with lots of RAM has some > difficulties to keep the framerate above 25 fps if you play three > clips at once and apply some complex effects. > > > ... pleXus > > > Am 28.04.2011 02:46, schrieb Grant Muir (Morph): >> >> >> On 15 April 2011 06:58, plexus <pl...@op... >> <mailto:pl...@op...>> wrote: >> >> Hi Morph, >> >> I silently hoping you're joking. But I think you don't. >> I don't think iOS is a good platform for ... well, anything. >> (sorry for my Apple - bashing) >> >> The problem is (as with any other suggestions of porting oTZT to >> a non-Windows platform) DirectX and the whole lot of assembler >> code which is specifically written for x86/Intel CPU's. >> >> Even a port to OpenGL which would make things easier to go from >> Windows to other platforms is insanely difficult. >> >> >> Yeah I'm not really talking a port, I'm more talking about builing it >> from scratch and just using the same ui/control/workflow >> >> >> >> >> > Would you be interested in collaborating on it? >> >> In general yes, but I'm currently pondering the possibilities to >> go entirely to 888 support, which already is a big undertaking, >> since one has to rewrite about 95% of the assembler code. >> >> >> > [...] thats going to take me alot of work to get going. >> >> Not just you, as I said, it's insanely complicated. The whole >> rendering engine is closely bonded to the DirectX API. (and >> assembler as I mentined earlier, which doesn't make the issue easier) >> >> >> Also, iOS seems to be the worst platform imaginable in terms of >> performance. >> >> >> I'm looking into learning how to code iOS apps over th next few weeks >> so I'll let you know my progress :) >> >> G >> >> >> >> bye, >> pleXus >> >> >> Am 10.04.2011 15:23, schrieb Grant Muir (Morph): >>> Hey mate, I'm thinking of replicating OpenTZT on iOS I think its >>> a great platform and would be awesome for a proper full VJ app >>> like Otzt. What do you think??? Would you be interested in >>> collaborating on it?? I'm a beginner prgrammer at best so it >>> something thats going to take me alot of work to get going. >>> >>> G >>> >>> -- >>> Grant Muir (Morph) >>> _________________________ >>> Morph Visual Services >>> mo...@mo... <mailto:mo...@mo...> >>> Ph: +61 (0) 412823786 >>> http://morphvisual.com >> >> >> >> >> -- >> Grant Muir (Morph) >> _________________________ >> Morph Visual Services >> mo...@mo... <mailto:mo...@mo...> >> Ph: +61 (0) 412823786 >> http://morphvisual.com > > > > ------------------------------------------------------------------------------ > WhatsUp Gold - Download Free Network Management Software > The most intuitive, comprehensive, and cost-effective network > management toolset available today. Delivers lowest initial > acquisition cost and overall TCO of any competing solution. > http://p.sf.net/sfu/whatsupgold-sd > > > _______________________________________________ > Opentzt-developers mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opentzt-developers |
|
From: plexus <pl...@op...> - 2011-05-04 16:13:18
|
Hi Morph, well, a build from scratch could work, but be aware: openTZT currently consists of about 33000 lines of code, maybe 4 to 5 percent in assembler. That's a lot of work. Is there a multimedia API for iOS ? Maybe the best way for you to start is to get as much documentation about multimedia programming for iOS as possible (especially for graphics). Also it's really important to know what video codecs are availabe and how they perform. You should do some performance tests with plain video first. Just to get a feeling for the performance in general. If a codec takes up most of the CPU power there's no way to make a decent VJ tool. Remember: even a modern dual core system with lots of RAM has some difficulties to keep the framerate above 25 fps if you play three clips at once and apply some complex effects. ... pleXus Am 28.04.2011 02:46, schrieb Grant Muir (Morph): > > > On 15 April 2011 06:58, plexus <pl...@op... > <mailto:pl...@op...>> wrote: > > Hi Morph, > > I silently hoping you're joking. But I think you don't. > I don't think iOS is a good platform for ... well, anything. > (sorry for my Apple - bashing) > > The problem is (as with any other suggestions of porting oTZT to a > non-Windows platform) DirectX and the whole lot of assembler code > which is specifically written for x86/Intel CPU's. > > Even a port to OpenGL which would make things easier to go from > Windows to other platforms is insanely difficult. > > > Yeah I'm not really talking a port, I'm more talking about builing it > from scratch and just using the same ui/control/workflow > > > > > > Would you be interested in collaborating on it? > > In general yes, but I'm currently pondering the possibilities to > go entirely to 888 support, which already is a big undertaking, > since one has to rewrite about 95% of the assembler code. > > > > [...] thats going to take me alot of work to get going. > > Not just you, as I said, it's insanely complicated. The whole > rendering engine is closely bonded to the DirectX API. (and > assembler as I mentined earlier, which doesn't make the issue easier) > > > Also, iOS seems to be the worst platform imaginable in terms of > performance. > > > I'm looking into learning how to code iOS apps over th next few weeks > so I'll let you know my progress :) > > G > > > > bye, > pleXus > > > Am 10.04.2011 15:23, schrieb Grant Muir (Morph): >> Hey mate, I'm thinking of replicating OpenTZT on iOS I think its >> a great platform and would be awesome for a proper full VJ app >> like Otzt. What do you think??? Would you be interested in >> collaborating on it?? I'm a beginner prgrammer at best so it >> something thats going to take me alot of work to get going. >> >> G >> >> -- >> Grant Muir (Morph) >> _________________________ >> Morph Visual Services >> mo...@mo... <mailto:mo...@mo...> >> Ph: +61 (0) 412823786 >> http://morphvisual.com > > > > > -- > Grant Muir (Morph) > _________________________ > Morph Visual Services > mo...@mo... <mailto:mo...@mo...> > Ph: +61 (0) 412823786 > http://morphvisual.com |
|
From: $3 B. <3d...@ca...> - 2011-05-02 12:11:34
|
The last time I checked 16-byte alignment was not an option with DirectX 7. DX8 and above should all support the 16-byte alignment option on textures. On Mon, May 2, 2011 at 6:15 AM, James Wise <jam...@gm...> wrote: > Well i'm hoping to use the SSE3 load that allows for unaligned loads :) > However i'm kind of surprised to hear that the textures are not 16-bit > aligned. > Is it possibly to make them aligned when they are assigned? > > I expect that the speed will vary greatly among processor families, but > that SSE 2/3 would most likely be faster on recent procs, basically anything > core Based or onwards would favor SSE. Obviously i will do some testing to > confirm any speed-ups, but the ability to process 8 pixels a cycle vs 4. > should be a pretty easy speedup. > > Having said all that it is also an chance to get familiar with tzt and SSE > code again. > Also and future 64-bit port would need to be SSEx, so it's another small > step in that direction. > (64-bit has twice as many SSE2 Regs, so thats another double in speed when > we do that) > > Thanks for the info though :) > > - James > > > > > Just so it's said... I would not assume that SSE2 is faster than ASM/MMX > in all instances, especially since the textures are not 16 byte aligned > (unless that has changed). Anytime I was coding "speed enhancements" I > would always run some real world tests to gauge the speed of the new code > against the old code. The speeds may vary across processor families, too, > but I would not expect anyone to spend too much time running all the > permutations. > > Cheers, > > Dave\Esotic > > > > On Wed, Apr 27, 2011 at 6:14 AM, James Wise <jam...@gm...> wrote: > >> Hey All, Plexus, >> >> > Got the same problem. That's why I concentrated on doing >> > "Janitor"-Work and GUI stuff at first. >> > But after the 1.6 release I have mostly DX9, 888, 64bit stuff on the >> > ToDo list. >> > (I wouldn't go above DX9 to still support XP) >> Like i said before i'm not big on the GUI layout, would be open to >> alternate suggestions? >> I like some of the changes, not all of them though. >> i could easily do up an image for others to critique/comment? >> >> Personally i think a clean break between the existing version, and a >> newer 64-bit version would be a good idea. >> Although i would think that any new 64bit, 888, version should be based >> on newer tech like windows7. >> I don't know many/any? people running 64-bit winXP systems? Given the >> amount of time such a project will take ie. likely a year or so >> I think that targeting windows7_64 is the best bet. Also we could get >> rid of GDI dependency easily then. >> >> > >> > Except for one big issue: The Clone Window Resizing (could be a movie >> > title :) >> > Thats on top if the list. The quality and resolution of video >> > projectors has improved much, so the poor resizing is really obvious >> > now and pretty annoying. >> > >> > Unfortunately, I have no idea what's the best way to do that. If >> > anyone has a good idea, please tell me. >> > >> Have you seen my post on the forums on sourceforge? >> I found a codeproject webpage that outlines a method of doing >> anti-aliased upscaling via GDI+/GDI >> I'm not sure how well it would perform but i think that this method >> would be a very easy way to increase the upscale quality >> >> >> http://www.codeproject.com/Tips/77955/GDIplus-Replacement-for-StretchBlt-With-Anti-Alias.aspx >> >> >> I'm still working on moving some of the asm/mmx code to SSE2, but it's >> slow going at the moment. >> >> Cheers, >> James / vj PiedPiper >> >> >> >> >> ------------------------------------------------------------------------------ >> WhatsUp Gold - Download Free Network Management Software >> The most intuitive, comprehensive, and cost-effective network >> management toolset available today. Delivers lowest initial >> acquisition cost and overall TCO of any competing solution. >> http://p.sf.net/sfu/whatsupgold-sd >> _______________________________________________ >> Opentzt-developers mailing list >> Ope...@li... >> https://lists.sourceforge.net/lists/listinfo/opentzt-developers >> > > > |
|
From: James W. <jam...@gm...> - 2011-05-02 10:15:46
|
Well i'm hoping to use the SSE3 load that allows for unaligned loads :) However i'm kind of surprised to hear that the textures are not 16-bit aligned. Is it possibly to make them aligned when they are assigned? I expect that the speed will vary greatly among processor families, but that SSE 2/3 would most likely be faster on recent procs, basically anything core Based or onwards would favor SSE. Obviously i will do some testing to confirm any speed-ups, but the ability to process 8 pixels a cycle vs 4. should be a pretty easy speedup. Having said all that it is also an chance to get familiar with tzt and SSE code again. Also and future 64-bit port would need to be SSEx, so it's another small step in that direction. (64-bit has twice as many SSE2 Regs, so thats another double in speed when we do that) Thanks for the info though :) - James > > Just so it's said... I would not assume that SSE2 is faster than > ASM/MMX in all instances, especially since the textures are not 16 > byte aligned (unless that has changed). Anytime I was coding "speed > enhancements" I would always run some real world tests to gauge the > speed of the new code against the old code. The speeds may vary > across processor families, too, but I would not expect anyone to spend > too much time running all the permutations. > > Cheers, > > Dave\Esotic > > > > On Wed, Apr 27, 2011 at 6:14 AM, James Wise <jam...@gm... > <mailto:jam...@gm...>> wrote: > > Hey All, Plexus, > > > Got the same problem. That's why I concentrated on doing > > "Janitor"-Work and GUI stuff at first. > > But after the 1.6 release I have mostly DX9, 888, 64bit stuff on the > > ToDo list. > > (I wouldn't go above DX9 to still support XP) > Like i said before i'm not big on the GUI layout, would be open to > alternate suggestions? > I like some of the changes, not all of them though. > i could easily do up an image for others to critique/comment? > > Personally i think a clean break between the existing version, and a > newer 64-bit version would be a good idea. > Although i would think that any new 64bit, 888, version should be > based > on newer tech like windows7. > I don't know many/any? people running 64-bit winXP systems? Given the > amount of time such a project will take ie. likely a year or so > I think that targeting windows7_64 is the best bet. Also we > could get > rid of GDI dependency easily then. > > > > > Except for one big issue: The Clone Window Resizing (could be a > movie > > title :) > > Thats on top if the list. The quality and resolution of video > > projectors has improved much, so the poor resizing is really obvious > > now and pretty annoying. > > > > Unfortunately, I have no idea what's the best way to do that. If > > anyone has a good idea, please tell me. > > > Have you seen my post on the forums on sourceforge? > I found a codeproject webpage that outlines a method of doing > anti-aliased upscaling via GDI+/GDI > I'm not sure how well it would perform but i think that this method > would be a very easy way to increase the upscale quality > > http://www.codeproject.com/Tips/77955/GDIplus-Replacement-for-StretchBlt-With-Anti-Alias.aspx > > > I'm still working on moving some of the asm/mmx code to SSE2, but it's > slow going at the moment. > > Cheers, > James / vj PiedPiper > > > > ------------------------------------------------------------------------------ > WhatsUp Gold - Download Free Network Management Software > The most intuitive, comprehensive, and cost-effective network > management toolset available today. Delivers lowest initial > acquisition cost and overall TCO of any competing solution. > http://p.sf.net/sfu/whatsupgold-sd > _______________________________________________ > Opentzt-developers mailing list > Ope...@li... > <mailto:Ope...@li...> > https://lists.sourceforge.net/lists/listinfo/opentzt-developers > > |
|
From: Grant M. (Morph) <mo...@mo...> - 2011-04-28 01:22:26
|
On 15 April 2011 07:38, plexus <pl...@op...> wrote: > Hi Morph, > > > > Although I do have to agree that splitting the EDIT/PLAY flip flop (where > the edit auto switches to the other bus when you use the keyboard (space, m, > etc) to change the play bus really shits me. > > How would you suggest this to work? (If you have an idea, please include > the working of the space/esc/tab key in this context) > the way it use to work in all the old versions (1.5), you could Tab to change Edit to either Bus, when you hit a mix key ( m,./ ) the Edit would automatically jump to the layer NOT Playing, Space switches Pay to non playing Bus, Esc switches Play to non playing Bus on Hold down.... > > > > > I have to say with most of my recent projects needing some sort of > scaling of clips not having per p/layer based position/zoom/stretch is > really driving me nuts and pushing me over to Modul8 more and more. > > I don't follow. Could you please explain in more detail? > I'm saying it would be great if each layer had its own position/pan, zoom and stretch controls like you can in modul8 or most fo the other major VJ apps these days, I'm sure you've seen the function. > > > > ... pleXus > > > > Am 14.04.2011 03:36, schrieb Grant Muir (Morph): > > Hey james for performance issues see my post on VJF > > On 13 April 2011 22:49, James Wise <jam...@gm...> wrote: > >> I'm not too big on the interface re-arrange, >> Not sure if i think it's an improvement. >> i definitely preferred the presets and player stuff along the bottom. >> > > Have to say I tend to agree on this. > >> >> I'm getting a bunch of yellow symbols where i suspect there should be just >> black empty space. >> the symbol looks like a ">|" sort of thing. >> > > Yeah that should be blank > >> >> the A/B mixer is good improvement, it's a bit slow for me, but i'm sure >> lots of other will love it. >> > > Yeah its pretty handy > >> >> No edit and play labels to show which Bus is which though??? >> - where do i click to change the edit BUS? >> > > Click?? What is this... band camp?? Although I do have to agree that > splitting the EDIT/PLAY flip flop (where the edit auto switches to the other > bus when you use the keyboard (space, m, etc) to change the play bus really > shits me. > >> >> I'm not 100% sure but i think it's a bit slower than 1.5.1 >> > > See my offer on VJF to work on testing this. > > I have to say with most of my recent projects needing some sort of > scaling of clips not having per p/layer based position/zoom/stretch is > really driving me nuts and pushing me over to Modul8 more and more. > >> >> >> >> Now for other things..... >> - I've made a new post on sourceforge, regarding the improved scaling, not >> GPU based, but it might be a simple way to get anti-alaising. >> >> - I've just got a new i7 Based laptop running win7 64-bit, and TzT isn't >> running much/any faster than my old Core2Duo winXP system. >> - I initially had problems with my Ati drivers, not supporting >> WDDM 1.1 and thus not getting any GDI acceleration, but this seems >> to be fixed no i have some new drivers. >> >> - But it has become clear that TzT is far from it's peak >> performance/ability due to being based on such old standards like GDI, old >> DX, and asm/MMX, when run on new platforms like 64-bit win7. the newly >> introduced "Direct2D" in Win7 seems to be a modern replacement for the old >> GDI, long term we might need to consider moving to that??? >> >> >> Anyway just my latest test results + ramblings, i'm happy to do more >> testing etc. over the next couple of weeks >> specific requests are always helpful. >> >> - Cheers, PiedPiper / james >> >> PS. has anyone tried a dumb compile to a x86_64 target?? >> >> >> >> >> >> On 14/08/2010 6:28 PM, Grant Muir (Morph) wrote: >> >> Thanks mate, will take it for a spin tomorrow :) >> >> G >> >> On 6 August 2010 07:06, plexus <pl...@op...> wrote: >> >>> Hi all, >>> >>> damn, my 1st message got blocked because of the attachment (mentioned >>> below), the file is available here: >>> >>> http://opentzt.cvs.sourceforge.net/viewvc/opentzt/release/openTZT_1_6_0_1b_binary_only.zip?revision=1.1 >>> >>> @morph: thanks for the test :) >>> >>> Sorry, I forgot to mention it in the release mail and in the changelog. >>> The autoswitcher moved to [Page Up]+[Space] since both the [Home] and the >>> [F12 key] is used for different functions. >>> >>> I attached a beta release build of openTZT 1.6. (You have to copy the >>> image files to \SysData\ and you should make a backup copy of the files that >>> will be overwritten) >>> I focused primarily on the GUI and the possibility to load files without >>> restart. (and the render engine keeps running *yeah* (was a bitch to write >>> ;)) >>> Most of the player and fx parameters are mouse controllable. Numeric >>> values are changed by the mouse y axis, scratching and the mixer is >>> controlled by the x axis. >>> The mouse code is still incomplete, though. >>> >>> I also added names for the fx parameters. The freeframe code isn't >>> written yet, but the first 17 internal fx have named parameters, already >>> :))) >>> Maybe anyone of you could suggest names for the other fx parameters, >>> since I'm german it's difficult to find names that are clear to everyone and >>> also fit into 8 characters. >>> It's even hard in german ;) >>> >>> >>> plexus ... >>> >>> >>>> >>>> >>>> >>>> Grant Muir (Morph) schrieb: >>>> >>>> Some more feedback, >>>>> >>>>> Everything is working great, I am also getting the small issue with the >>>>> config tool, but its nothing I can't work around. >>>>> >>>>> No crashes for me, even used it 5+ hours @ a corp gig and no one hiccup >>>>> :) >>>>> >>>>> One small issue, it seems for some reason the Home + Space keyboard >>>>> shortcut to start Auto Switching isn't working in the new version. >>>>> >>>>> otherwise great, I have a few other suggestions but will save them for >>>>> after I get back from Japan. >>>>> >>>>> G >>>>> >>>> >>>> >>> >> >> >> -- >> Grant Muir (Morph) >> _________________________ >> Morph Visual Services >> mo...@mo... >> Ph: +61 (0) 412823786 >> http://morphvisual.com >> >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by >> >> Make an app they can't live without >> Enter the BlackBerry Developer Challengehttp://p.sf.net/sfu/RIM-dev2dev >> >> >> _______________________________________________ >> Opentzt-developers mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/opentzt-developers >> >> >> >> >> ------------------------------------------------------------------------------ >> Forrester Wave Report - Recovery time is now measured in hours and minutes >> not days. Key insights are discussed in the 2010 Forrester Wave Report as >> part of an in-depth evaluation of disaster recovery service providers. >> Forrester found the best-in-class provider in terms of services and >> vision. >> Read this report now! http://p.sf.net/sfu/ibm-webcastpromo >> _______________________________________________ >> Opentzt-developers mailing list >> Ope...@li... >> https://lists.sourceforge.net/lists/listinfo/opentzt-developers >> >> > > > -- > Grant Muir (Morph) > _________________________ > Morph Visual Services > mo...@mo... > Ph: +61 (0) 412823786 > http://morphvisual.com > > > ------------------------------------------------------------------------------ > Benefiting from Server Virtualization: Beyond Initial Workload > Consolidation -- Increasing the use of server virtualization is a top > priority.Virtualization can reduce costs, simplify management, and improve > application availability and disaster protection. Learn more about boosting > the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev > > > _______________________________________________ > Opentzt-developers mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/opentzt-developers > > > -- Grant Muir (Morph) _________________________ Morph Visual Services mo...@mo... Ph: +61 (0) 412823786 http://morphvisual.com |
|
From: Grant M. (Morph) <vj...@gm...> - 2011-04-28 00:47:11
|
On 15 April 2011 06:58, plexus <pl...@op...> wrote: > Hi Morph, > > I silently hoping you're joking. But I think you don't. > I don't think iOS is a good platform for ... well, anything. (sorry for my > Apple - bashing) > > The problem is (as with any other suggestions of porting oTZT to a > non-Windows platform) DirectX and the whole lot of assembler code which is > specifically written for x86/Intel CPU's. > > Even a port to OpenGL which would make things easier to go from Windows to > other platforms is insanely difficult. > Yeah I'm not really talking a port, I'm more talking about builing it from scratch and just using the same ui/control/workflow > > > > > Would you be interested in collaborating on it? > > In general yes, but I'm currently pondering the possibilities to go > entirely to 888 support, which already is a big undertaking, since one has > to rewrite about 95% of the assembler code. > > > > [...] thats going to take me alot of work to get going. > > Not just you, as I said, it's insanely complicated. The whole rendering > engine is closely bonded to the DirectX API. (and assembler as I mentined > earlier, which doesn't make the issue easier) > > > Also, iOS seems to be the worst platform imaginable in terms of > performance. > I'm looking into learning how to code iOS apps over th next few weeks so I'll let you know my progress :) G > > > bye, > pleXus > > > Am 10.04.2011 15:23, schrieb Grant Muir (Morph): > > Hey mate, I'm thinking of replicating OpenTZT on iOS I think its a great > platform and would be awesome for a proper full VJ app like Otzt. What do > you think??? Would you be interested in collaborating on it?? I'm a beginner > prgrammer at best so it something thats going to take me alot of work to get > going. > > G > > -- > Grant Muir (Morph) > _________________________ > Morph Visual Services > mo...@mo... > Ph: +61 (0) 412823786 > http://morphvisual.com > > > -- Grant Muir (Morph) _________________________ Morph Visual Services mo...@mo... Ph: +61 (0) 412823786 http://morphvisual.com |
|
From: plexus <pl...@op...> - 2011-04-27 18:30:29
|
Hi James, > Like i said before i'm not big on the GUI layout, would be open to alternate suggestions? Of course. I'm not entirely happy with it either, but my main goals were A: to keep the main window 800x600, B: have all parameters of the players and the effects visible and C: keep the amount of rewriting as small as possible, because: I started writing a completely new GUI engine some time ago (pre 1.5.1) but put it on the shelf to do more important work on the render engine. That new code will run in a separate thread and allows to resize the main window dynamically. The plan is to introduce this new GUI with the 1.7 but it's not finished and will require some work too. > Personally i think a clean break between the existing version, and a newer 64-bit version would be a good idea. Although i would think that any new 64bit, 888, version should be based on newer tech like windows7 The idea is good, but even now it's not easy to maintain the tool. It's a huge chunk of work and I'm not sure we could pull it off. Let alone the amount of reading and learning the new DX10/11 stuff. Maybe we're better off doing small steps. > Have you seen my post on the forums on sourceforge? I didn't. Looks good though. I'll give it a try. bye, pleXus Am 27.04.2011 12:14, schrieb James Wise: > Hey All, Plexus, > >> Got the same problem. That's why I concentrated on doing >> "Janitor"-Work and GUI stuff at first. >> But after the 1.6 release I have mostly DX9, 888, 64bit stuff on the >> ToDo list. >> (I wouldn't go above DX9 to still support XP) > Like i said before i'm not big on the GUI layout, would be open to > alternate suggestions? > I like some of the changes, not all of them though. > i could easily do up an image for others to critique/comment? > > Personally i think a clean break between the existing version, and a > newer 64-bit version would be a good idea. > Although i would think that any new 64bit, 888, version should be based > on newer tech like windows7. > I don't know many/any? people running 64-bit winXP systems? Given the > amount of time such a project will take ie. likely a year or so > I think that targeting windows7_64 is the best bet. Also we could get > rid of GDI dependency easily then. > >> Except for one big issue: The Clone Window Resizing (could be a movie >> title :) >> Thats on top if the list. The quality and resolution of video >> projectors has improved much, so the poor resizing is really obvious >> now and pretty annoying. >> >> Unfortunately, I have no idea what's the best way to do that. If >> anyone has a good idea, please tell me. >> > Have you seen my post on the forums on sourceforge? > I found a codeproject webpage that outlines a method of doing > anti-aliased upscaling via GDI+/GDI > I'm not sure how well it would perform but i think that this method > would be a very easy way to increase the upscale quality > > http://www.codeproject.com/Tips/77955/GDIplus-Replacement-for-StretchBlt-With-Anti-Alias.aspx > > > I'm still working on moving some of the asm/mmx code to SSE2, but it's > slow going at the moment. > > Cheers, > James / vj PiedPiper > > > > ------------------------------------------------------------------------------ > WhatsUp Gold - Download Free Network Management Software > The most intuitive, comprehensive, and cost-effective network > management toolset available today. Delivers lowest initial > acquisition cost and overall TCO of any competing solution. > http://p.sf.net/sfu/whatsupgold-sd > _______________________________________________ > Opentzt-developers mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opentzt-developers > |
|
From: $3 B. <3d...@ca...> - 2011-04-27 12:34:14
|
Just so it's said... I would not assume that SSE2 is faster than ASM/MMX in all instances, especially since the textures are not 16 byte aligned (unless that has changed). Anytime I was coding "speed enhancements" I would always run some real world tests to gauge the speed of the new code against the old code. The speeds may vary across processor families, too, but I would not expect anyone to spend too much time running all the permutations. Cheers, Dave\Esotic On Wed, Apr 27, 2011 at 6:14 AM, James Wise <jam...@gm...> wrote: > Hey All, Plexus, > > > Got the same problem. That's why I concentrated on doing > > "Janitor"-Work and GUI stuff at first. > > But after the 1.6 release I have mostly DX9, 888, 64bit stuff on the > > ToDo list. > > (I wouldn't go above DX9 to still support XP) > Like i said before i'm not big on the GUI layout, would be open to > alternate suggestions? > I like some of the changes, not all of them though. > i could easily do up an image for others to critique/comment? > > Personally i think a clean break between the existing version, and a > newer 64-bit version would be a good idea. > Although i would think that any new 64bit, 888, version should be based > on newer tech like windows7. > I don't know many/any? people running 64-bit winXP systems? Given the > amount of time such a project will take ie. likely a year or so > I think that targeting windows7_64 is the best bet. Also we could get > rid of GDI dependency easily then. > > > > > Except for one big issue: The Clone Window Resizing (could be a movie > > title :) > > Thats on top if the list. The quality and resolution of video > > projectors has improved much, so the poor resizing is really obvious > > now and pretty annoying. > > > > Unfortunately, I have no idea what's the best way to do that. If > > anyone has a good idea, please tell me. > > > Have you seen my post on the forums on sourceforge? > I found a codeproject webpage that outlines a method of doing > anti-aliased upscaling via GDI+/GDI > I'm not sure how well it would perform but i think that this method > would be a very easy way to increase the upscale quality > > > http://www.codeproject.com/Tips/77955/GDIplus-Replacement-for-StretchBlt-With-Anti-Alias.aspx > > > I'm still working on moving some of the asm/mmx code to SSE2, but it's > slow going at the moment. > > Cheers, > James / vj PiedPiper > > > > > ------------------------------------------------------------------------------ > WhatsUp Gold - Download Free Network Management Software > The most intuitive, comprehensive, and cost-effective network > management toolset available today. Delivers lowest initial > acquisition cost and overall TCO of any competing solution. > http://p.sf.net/sfu/whatsupgold-sd > _______________________________________________ > Opentzt-developers mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opentzt-developers > |
|
From: James W. <jam...@gm...> - 2011-04-27 10:15:06
|
Hey All, Plexus, > Got the same problem. That's why I concentrated on doing > "Janitor"-Work and GUI stuff at first. > But after the 1.6 release I have mostly DX9, 888, 64bit stuff on the > ToDo list. > (I wouldn't go above DX9 to still support XP) Like i said before i'm not big on the GUI layout, would be open to alternate suggestions? I like some of the changes, not all of them though. i could easily do up an image for others to critique/comment? Personally i think a clean break between the existing version, and a newer 64-bit version would be a good idea. Although i would think that any new 64bit, 888, version should be based on newer tech like windows7. I don't know many/any? people running 64-bit winXP systems? Given the amount of time such a project will take ie. likely a year or so I think that targeting windows7_64 is the best bet. Also we could get rid of GDI dependency easily then. > > Except for one big issue: The Clone Window Resizing (could be a movie > title :) > Thats on top if the list. The quality and resolution of video > projectors has improved much, so the poor resizing is really obvious > now and pretty annoying. > > Unfortunately, I have no idea what's the best way to do that. If > anyone has a good idea, please tell me. > Have you seen my post on the forums on sourceforge? I found a codeproject webpage that outlines a method of doing anti-aliased upscaling via GDI+/GDI I'm not sure how well it would perform but i think that this method would be a very easy way to increase the upscale quality http://www.codeproject.com/Tips/77955/GDIplus-Replacement-for-StretchBlt-With-Anti-Alias.aspx I'm still working on moving some of the asm/mmx code to SSE2, but it's slow going at the moment. Cheers, James / vj PiedPiper |
|
From: plexus <pl...@op...> - 2011-04-20 11:10:44
|
Hi James, @All I had some mailing problems so I continued the conversation with James off the mailing list, see below to catch up. ----- Ok, now back to the discussion @James > - Why do you reply to me directly instead of keeping it on the mailing list?? The first mail I wrote had this huge attachment. I know sourceforge allows only very small attachments, so I dropped the mailing list. In the second mail I just forgot. > i think we should aim for a 64-bit version of TZT Agreed. Do you think it's possible to have still just one source, or do we have to fork the code? > I have no idea how hard a progressive change to 32bit colour would be???? Me neither. But I'm afraid it would be hard. All the assembler code has to be rewitten completely. > [...] never got very far, always trying to do too big steps Got the same problem. That's why I concentrated on doing "Janitor"-Work and GUI stuff at first. But after the 1.6 release I have mostly DX9, 888, 64bit stuff on the ToDo list. (I wouldn't go above DX9 to still support XP) Except for one big issue: The Clone Window Resizing (could be a movie title :) Thats on top if the list. The quality and resolution of video projectors has improved much, so the poor resizing is really obvious now and pretty annoying. Unfortunately, I have no idea what's the best way to do that. If anyone has a good idea, please tell me. > For some reason i have been taken of the project membership list?? Sure? You're listed as piedpiper. Or do you mean your name disappeared from the project start page? Anyway, I "refreshed" your entry, maybe this has some effect. ... pleXus Am 19.04.2011 13:25, schrieb James Wise: > Hey Plexus, > > Thanks for the older Libs etc. > I have got everything in order now and can finally build the project > properly. > I still get a few errors when compiling the Source as it exists in > Sourceforge, but nothing serious - However it would be nice to get > them resolved. > All the errors are from missing "int" before declaring a value, i > think this is due to changes in the compilers etc. > > Ahh well it sounds like you have gone one step further than i have in > terms of profiling the code, i do hope to be able to do that sometime, > but doubt i will get to it soon. > I too am new to Win7 / 64-bit and am on a bit of a learning curve myself. > > No my first task will be a basic mmx -> SSE2 conversion, using the > intrinsics in visual studio, in theory it should offer about double > the speed as it process twice the data width, but we will see. > If/when i get more familiar with the SSE2/3 code i will look at > updating other parts of the program. I have noticed that a fair > amount is in mmx, whihc should actually be relatively easy to port to > SSE2. > > No plans to make it 888 safe yet, but it should be a simple enough > operation once the loop is in SSE2 intrinsics. > IMHO, i think we should aim for a 64-bit version of TZT, that uses > 32-bit RGB, that should in theory not be any slower than current > 32-bit TZT using 16-bit RGB. > I have no idea how hard a progressive change to 32bit colour would be???? > > > Do you mean general programming experience or TZT experience? > General experience: write code for a living, but currently writing > drivers on OSX. used to work on a high end colour grading system where > i did a bit of SSE work. > TZT experience: tried to contribute a couple of times, never got very > far, always trying to do too big steps, i think esotic committed some > of my changes years ago ? > For some reason i have been taken of the project membership list?? > > As for moving stuff to the GPU, well that looks very complex given the > nature of the render pipeline, > I have started to look at Direct2D in windows7, whihc might offer a > good upgrade from GDI, whilst also giving us GPU > functionality/performance...... > > anyway i will start on these SSE changes and let u know how i go. > > > - Why do you reply to me directly instead of keeping it on the mailing > list?? > i know there isn't many people on the list, but i liek to keep > everyone involved with whats going on? > > Cheers, vj PiedPiper / James > > > > > On 18/04/2011 9:12 PM, plexus wrote: >> Hi PiedPiper , >> >> seems you do need older libraries. Since I won't build the 1.6 with >> VS2008 I installed VS2003 on my system (win7x64), and the includes >> came with it. >> I attached the library to my previous mail, but I got a failure >> notice. The notice contained this link: >> http://mail.google.com/support/bin/answer.py?answer=6590 >> Obviously Google doesn't like .lib files :( >> >> You can download it here (size: 12MB) : >> http://opal-city.de/plexus/PlatformSDK.zip >> >> >> I'm not sure the lib will work, but it built fine on my system. >> >> >> > [...] i don't think the decoding is the bottleneck >> >> During development of the multithreading code I did some performance >> measurements. In many cases it was the decoder which took the most >> time to return (compared to some of the FX). >> I can't speak for 64bit codecs. Only now I'm able to try 64bit stuff. >> (I installed win7 only 2 weeks ago) >> >> >> > My current task/goal, is to take some of the composition code, and >> re-factor it from asm/mmx into SSE2. >> >> That's Great :) What's your experience so far? >> Do you plan to make it ready for RGB888 ? That would be even better, >> since oTZT hast to get ready for 24/32 bit color depth. >> I currently plan on starting with the easier effects, especially the >> ones which doesn't work for 888. >> Which documentation you use for SSE2 ? >> >> A co-worker of mine started to rewrite the unfinished emboss FX to >> get familliar with SSE2/3/4 (which it isn't currently). >> We decided for now to keep the rendering on the CPU. GPU stuff is >> much harder to implement in the current render pipeline. >> Besides, due to the back and forth between sys-mem and graphics-mem >> it probably wouldn't make it any faster. >> >> >> bye, >> plexus >> >> Am 17.04.2011 09:57, schrieb James Wise: >>> Hey Plexus, >>> >>> where did u get the "d3dxcore.h" ... and all the other associated >>> older includes and Libs for win7?? >>> I have the latest DX SDK, and the latest platform SDK for win7, but >>> i cant find those files in either of those packages? >>> Do i need to get an older SDK or something? >>> >>> I have only previously compiled tzt on XP? >>> >>> I use FFDshow as the decoder for most of my codecs, including mjpeg >>> - and they have a 64-bit version of the codecs, which i think i'm >>> using, and i assume must be quite optimissed, so in my primary >>> testing scenario's i don't think the decoding is the bottleneck. >>> >>> >>> My current task/goal, is to take some of the composition code, and >>> re-factor it from asm/mmx into SSE2. >>> which should give maybe double in performance for that specific >>> operation. >>> that is, add/subtract/alpha layer stuff etc. >>> >>> Cheers, >>> >>> PiedPiper >>> >>> |
|
From: James W. <jam...@gm...> - 2011-04-17 07:57:40
|
Hey Plexus, where did u get the "d3dxcore.h" ... and all the other associated older includes and Libs for win7?? I have the latest DX SDK, and the latest platform SDK for win7, but i cant find those files in either of those packages? Do i need to get an older SDK or something? I have only previously compiled tzt on XP? I use FFDshow as the decoder for most of my codecs, including mjpeg - and they have a 64-bit version of the codecs, which i think i'm using, and i assume must be quite optimissed, so in my primary testing scenario's i don't think the decoding is the bottleneck. My current task/goal, is to take some of the composition code, and re-factor it from asm/mmx into SSE2. which should give maybe double in performance for that specific operation. that is, add/subtract/alpha layer stuff etc. Cheers, PiedPiper > > I too have now Win7/64, and yes, the performance doesn't improve, > which isn't surprising since oTZT uses 10 years old libraries. I'm > thinking about updating, but where do I start ??? The whole render > engine is totally outdated (three words: 565 color depth !!!). > It's just frustrating. Even such simple things like antialiased > scaling for the clone window is far from easy :( > And if I do it old school, it's slow. I thought about going right to > GPU support, but the Documentation is like 300 pages long and a > completely new technology to me :( > > > > PS. has anyone tried a dumb compile to a x86_64 target?? > > Yes, but it doesn't make a difference since most of the critical code > is in assembler and I can't do anything about the codecs (which are > the still the most significant bottleneck). > > > ... pleXus > > P.S. don't blame it on the GDI, it's only used for the clone window. > Blame it on DirectX 7. ;) > BTW: the old GDI is actually quite fast. :) > |
|
From: Grant M. (Morph) <mo...@mo...> - 2011-04-14 01:37:12
|
Hey james for performance issues see my post on VJF On 13 April 2011 22:49, James Wise <jam...@gm...> wrote: > I'm not too big on the interface re-arrange, > Not sure if i think it's an improvement. > i definitely preferred the presets and player stuff along the bottom. > Have to say I tend to agree on this. > > I'm getting a bunch of yellow symbols where i suspect there should be just > black empty space. > the symbol looks like a ">|" sort of thing. > Yeah that should be blank > > the A/B mixer is good improvement, it's a bit slow for me, but i'm sure > lots of other will love it. > Yeah its pretty handy > > No edit and play labels to show which Bus is which though??? > - where do i click to change the edit BUS? > Click?? What is this... band camp?? Although I do have to agree that splitting the EDIT/PLAY flip flop (where the edit auto switches to the other bus when you use the keyboard (space, m, etc) to change the play bus really shits me. > > I'm not 100% sure but i think it's a bit slower than 1.5.1 > See my offer on VJF to work on testing this. I have to say with most of my recent projects needing some sort of scaling of clips not having per p/layer based position/zoom/stretch is really driving me nuts and pushing me over to Modul8 more and more. > > > > Now for other things..... > - I've made a new post on sourceforge, regarding the improved scaling, not > GPU based, but it might be a simple way to get anti-alaising. > > - I've just got a new i7 Based laptop running win7 64-bit, and TzT isn't > running much/any faster than my old Core2Duo winXP system. > - I initially had problems with my Ati drivers, not supporting WDDM > 1.1 and thus not getting any GDI acceleration, but this seems > to be fixed no i have some new drivers. > > - But it has become clear that TzT is far from it's peak > performance/ability due to being based on such old standards like GDI, old > DX, and asm/MMX, when run on new platforms like 64-bit win7. the newly > introduced "Direct2D" in Win7 seems to be a modern replacement for the old > GDI, long term we might need to consider moving to that??? > > > Anyway just my latest test results + ramblings, i'm happy to do more > testing etc. over the next couple of weeks > specific requests are always helpful. > > - Cheers, PiedPiper / james > > PS. has anyone tried a dumb compile to a x86_64 target?? > > > > > > On 14/08/2010 6:28 PM, Grant Muir (Morph) wrote: > > Thanks mate, will take it for a spin tomorrow :) > > G > > On 6 August 2010 07:06, plexus <pl...@op...> wrote: > >> Hi all, >> >> damn, my 1st message got blocked because of the attachment (mentioned >> below), the file is available here: >> >> http://opentzt.cvs.sourceforge.net/viewvc/opentzt/release/openTZT_1_6_0_1b_binary_only.zip?revision=1.1 >> >> @morph: thanks for the test :) >> >> Sorry, I forgot to mention it in the release mail and in the changelog. >> The autoswitcher moved to [Page Up]+[Space] since both the [Home] and the >> [F12 key] is used for different functions. >> >> I attached a beta release build of openTZT 1.6. (You have to copy the >> image files to \SysData\ and you should make a backup copy of the files that >> will be overwritten) >> I focused primarily on the GUI and the possibility to load files without >> restart. (and the render engine keeps running *yeah* (was a bitch to write >> ;)) >> Most of the player and fx parameters are mouse controllable. Numeric >> values are changed by the mouse y axis, scratching and the mixer is >> controlled by the x axis. >> The mouse code is still incomplete, though. >> >> I also added names for the fx parameters. The freeframe code isn't written >> yet, but the first 17 internal fx have named parameters, already :))) >> Maybe anyone of you could suggest names for the other fx parameters, since >> I'm german it's difficult to find names that are clear to everyone and also >> fit into 8 characters. >> It's even hard in german ;) >> >> >> plexus ... >> >> >>> >>> >>> >>> Grant Muir (Morph) schrieb: >>> >>> Some more feedback, >>>> >>>> Everything is working great, I am also getting the small issue with the >>>> config tool, but its nothing I can't work around. >>>> >>>> No crashes for me, even used it 5+ hours @ a corp gig and no one hiccup >>>> :) >>>> >>>> One small issue, it seems for some reason the Home + Space keyboard >>>> shortcut to start Auto Switching isn't working in the new version. >>>> >>>> otherwise great, I have a few other suggestions but will save them for >>>> after I get back from Japan. >>>> >>>> G >>>> >>> >>> >> > > > -- > Grant Muir (Morph) > _________________________ > Morph Visual Services > mo...@mo... > Ph: +61 (0) 412823786 > http://morphvisual.com > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by > > Make an app they can't live without > Enter the BlackBerry Developer Challengehttp://p.sf.net/sfu/RIM-dev2dev > > > _______________________________________________ > Opentzt-developers mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/opentzt-developers > > > > > ------------------------------------------------------------------------------ > Forrester Wave Report - Recovery time is now measured in hours and minutes > not days. Key insights are discussed in the 2010 Forrester Wave Report as > part of an in-depth evaluation of disaster recovery service providers. > Forrester found the best-in-class provider in terms of services and vision. > Read this report now! http://p.sf.net/sfu/ibm-webcastpromo > _______________________________________________ > Opentzt-developers mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opentzt-developers > > -- Grant Muir (Morph) _________________________ Morph Visual Services mo...@mo... Ph: +61 (0) 412823786 http://morphvisual.com |
|
From: James W. <jam...@gm...> - 2011-04-13 12:49:28
|
I'm not too big on the interface re-arrange,
Not sure if i think it's an improvement.
i definitely preferred the presets and player stuff along the bottom.
I'm getting a bunch of yellow symbols where i suspect there should be
just black empty space.
the symbol looks like a ">|" sort of thing.
the A/B mixer is good improvement, it's a bit slow for me, but i'm sure
lots of other will love it.
No edit and play labels to show which Bus is which though???
- where do i click to change the edit BUS?
I'm not 100% sure but i think it's a bit slower than 1.5.1
Now for other things.....
- I've made a new post on sourceforge, regarding the improved scaling,
not GPU based, but it might be a simple way to get anti-alaising.
- I've just got a new i7 Based laptop running win7 64-bit, and TzT isn't
running much/any faster than my old Core2Duo winXP system.
- I initially had problems with my Ati drivers, not supporting
WDDM 1.1 and thus not getting any GDI acceleration, but this seems
to be fixed no i have some new drivers.
- But it has become clear that TzT is far from it's peak
performance/ability due to being based on such old standards like GDI,
old DX, and asm/MMX, when run on new platforms like 64-bit win7. the
newly introduced "Direct2D" in Win7 seems to be a modern replacement
for the old GDI, long term we might need to consider moving to that???
Anyway just my latest test results + ramblings, i'm happy to do more
testing etc. over the next couple of weeks
specific requests are always helpful.
- Cheers, PiedPiper / james
PS. has anyone tried a dumb compile to a x86_64 target??
On 14/08/2010 6:28 PM, Grant Muir (Morph) wrote:
> Thanks mate, will take it for a spin tomorrow :)
>
> G
>
> On 6 August 2010 07:06, plexus <pl...@op...
> <mailto:pl...@op...>> wrote:
>
> Hi all,
>
> damn, my 1st message got blocked because of the attachment
> (mentioned below), the file is available here:
> http://opentzt.cvs.sourceforge.net/viewvc/opentzt/release/openTZT_1_6_0_1b_binary_only.zip?revision=1.1
>
> @morph: thanks for the test :)
>
> Sorry, I forgot to mention it in the release mail and in the
> changelog.
> The autoswitcher moved to [Page Up]+[Space] since both the [Home]
> and the [F12 key] is used for different functions.
>
> I attached a beta release build of openTZT 1.6. (You have to copy
> the image files to \SysData\ and you should make a backup copy of
> the files that will be overwritten)
> I focused primarily on the GUI and the possibility to load files
> without restart. (and the render engine keeps running *yeah* (was
> a bitch to write ;))
> Most of the player and fx parameters are mouse controllable.
> Numeric values are changed by the mouse y axis, scratching and the
> mixer is controlled by the x axis.
> The mouse code is still incomplete, though.
>
> I also added names for the fx parameters. The freeframe code isn't
> written yet, but the first 17 internal fx have named parameters,
> already :)))
> Maybe anyone of you could suggest names for the other fx
> parameters, since I'm german it's difficult to find names that are
> clear to everyone and also fit into 8 characters.
> It's even hard in german ;)
>
>
> plexus ...
>
>
>
>
>
> Grant Muir (Morph) schrieb:
>
> Some more feedback,
>
> Everything is working great, I am also getting the small
> issue with the config tool, but its nothing I can't work
> around.
>
> No crashes for me, even used it 5+ hours @ a corp gig and
> no one hiccup :)
>
> One small issue, it seems for some reason the Home + Space
> keyboard shortcut to start Auto Switching isn't working in
> the new version.
>
> otherwise great, I have a few other suggestions but will
> save them for after I get back from Japan.
>
> G
>
>
>
>
>
>
> --
> Grant Muir (Morph)
> _________________________
> Morph Visual Services
> mo...@mo... <mailto:mo...@mo...>
> Ph: +61 (0) 412823786
> http://morphvisual.com
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
>
>
> _______________________________________________
> Opentzt-developers mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opentzt-developers
|
|
From: s t i j n <st...@jo...> - 2011-03-09 15:01:49
|
Thanks man! Testing this weekend. stijn On 8 mrt 2011 22:41 "plexus" <pl...@op...> <pl...@op...> wrote: > Greetings fellow coders > There's a new beta version of openTZT online. > see here: <http://opentzt.cvs.sourceforge.net/viewvc/opentzt/release/> > Note: you'll have to copy the two bitmaps in your /SysData/ folder. > You > can overwrite the existing files, it won't damage anything. > So, what's new? > Not much. > I added a dialog window to load files for a whole page or multiple > pages > at once. > A friend of mine (sillery), who's also a new project member, he > completed the mouse code for the APP buttons. > GUI facelift goes on too: FreeFrame parameter names are now shown next > to FX. > It's a bit confusing at first, but to get as much of the name as > possible onto the GUI it's wrapped around to the second line. > For some more information see: > <http://opentzt.cvs.sourceforge.net/viewvc/opentzt/release/change.log? > revision=1.5&view=markup> > Since the 1.6 got a full facelift I think it's good to put out a final > release as soon as possible. > The ToDo is still long, but it would took some time to get it done. > Currently we have a shiny new version which actually looks shiny and > new. > The last release (1.5.1) was also quite shiny and new compared to the > 1.5 but that wasn't obvious to the user since the most work was done > under the hood. > So, if no one complains I would just fix some issues that remained > from > the GUI facelift and then put out a 1.6 final without adding new > features. > I almost forgot: The CVS repository is up to date. It's the code I > built > the 1.6.0.2b from. > See ya, > pleXus > ---------------------------------------------------------------------- > -------- > What You Don't Know About Data Connectivity CAN Hurt You > This paper provides an overview of data connectivity, details > its effect on application quality, and explores various alternative > solutions. <http://p.sf.net/sfu/progress-d2d> > _______________________________________________ > Opentzt-developers mailing list > <Ope...@li...> > <https://lists.sourceforge.net/lists/listinfo/opentzt-developers> |
|
From: Grant M. (Morph) <mo...@mo...> - 2011-03-08 22:20:02
|
Nice one mate, flat out touring @ the moment, but finished next week... so I'll give it some testing then :) G On 9 March 2011 08:41, plexus <pl...@op...> wrote: > Greetings fellow coders > > There's a new beta version of openTZT online. > see here: http://opentzt.cvs.sourceforge.net/viewvc/opentzt/release/ > > Note: you'll have to copy the two bitmaps in your /SysData/ folder. You > can overwrite the existing files, it won't damage anything. > > So, what's new? > > Not much. > I added a dialog window to load files for a whole page or multiple pages > at once. > A friend of mine (sillery), who's also a new project member, he > completed the mouse code for the APP buttons. > GUI facelift goes on too: FreeFrame parameter names are now shown next > to FX. > It's a bit confusing at first, but to get as much of the name as > possible onto the GUI it's wrapped around to the second line. > > For some more information see: > http://opentzt.cvs.sourceforge.net/viewvc/opentzt/release/change.log?revision=1.5&view=markup > > > Since the 1.6 got a full facelift I think it's good to put out a final > release as soon as possible. > The ToDo is still long, but it would took some time to get it done. > Currently we have a shiny new version which actually looks shiny and new. > The last release (1.5.1) was also quite shiny and new compared to the > 1.5 but that wasn't obvious to the user since the most work was done > under the hood. > > So, if no one complains I would just fix some issues that remained from > the GUI facelift and then put out a 1.6 final without adding new features. > > I almost forgot: The CVS repository is up to date. It's the code I built > the 1.6.0.2b from. > > > See ya, > pleXus > > > > > ------------------------------------------------------------------------------ > What You Don't Know About Data Connectivity CAN Hurt You > This paper provides an overview of data connectivity, details > its effect on application quality, and explores various alternative > solutions. http://p.sf.net/sfu/progress-d2d > _______________________________________________ > Opentzt-developers mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opentzt-developers > -- Grant Muir (Morph) _________________________ Morph Visual Services mo...@mo... Ph: +61 (0) 412823786 http://morphvisual.com |
729 messages has been excluded from this view by a project administrator.
