TheLastBanana
|
|
« Reply #4080 on: May 07, 2013, 01:42:44 PM » |
|
Ah, thanks for the link. The slideshow itself is fine; it's the YouTube API that was giving me trouble. Somehow (and I'm still not sure how, which is worrying), I managed to fix the problem. This is what I was setting up, in case you're curious: http://www.mildlydisconcerting.com/portfolio/
|
|
|
Logged
|
|
|
|
Klaim
|
|
« Reply #4081 on: May 07, 2013, 01:58:52 PM » |
|
Oh ok I see now. Only thing is the time to load the whole thing is a bit long but otherwise it works well.
|
|
|
Logged
|
|
|
|
Will Vale
|
|
« Reply #4082 on: May 07, 2013, 02:16:18 PM » |
|
Making this even more obnoxious is that the YouTube API only works locally in Firefox, so to test my page in Chrome or IE, I have to upload it to a webserver first. I've been trying to solve this one issue for days.
For testing this kind of thing, you should absolutely install a webserver on your PC and run it on e.g. 8080. No uploads, proper testing. Use LAMP/WAMP and it's very easy: http://www.wampserver.com/en/
|
|
|
Logged
|
|
|
|
TheLastBanana
|
|
« Reply #4083 on: May 07, 2013, 03:01:38 PM » |
|
Oh ok I see now. Only thing is the time to load the whole thing is a bit long but otherwise it works well.
Yeah, it's pretty annoying. Unfortunately, it's pretty much necessary to load all the YouTube videos in. I might take a stab at having them loaded lazily later (i.e. when you navigate to the page they're contained in. Making this even more obnoxious is that the YouTube API only works locally in Firefox, so to test my page in Chrome or IE, I have to upload it to a webserver first. I've been trying to solve this one issue for days.
For testing this kind of thing, you should absolutely install a webserver on your PC and run it on e.g. 8080. No uploads, proper testing. Use LAMP/WAMP and it's very easy: http://www.wampserver.com/en/I really should have thought of that. Thanks for the link — I'll definitely do that next time.
|
|
|
Logged
|
|
|
|
Pishtaco
|
|
« Reply #4084 on: May 07, 2013, 11:27:27 PM » |
|
I'm warping an image in flash, using pixelbender. The warping calculation is a little slow, so I'm trying to store the actual transformation in a bitmap, in which the colour of pixel p contains the coordinates of a pixel q, and when you do the warp, to colour p you look up the colour at q. I'm using largeish images, so I want to use two colour channels for each co-ordinate of q. I've been getting weird artifacts, and after some digging I've discovered that flash stores its bitmaps internally with premultiplied alpha.
|
|
|
Logged
|
|
|
|
Pishtaco
|
|
« Reply #4085 on: May 07, 2013, 11:39:53 PM » |
|
(so the issue is that if I store a small value in the alpha channel, this screws up the precision of the other channels)
Ok, thought of a horrible fix. I would like images that are up to 3200 pixels wide, and to have some subpixel information in the coordinates (so that linear sampling will smooth out the warping), so I don't need 16 bits per coordinate but 13-14 would be good.
So I can store 7 bits in the alpha channel, in the range 0.5-1.0. Then in each colour channel I can also store 7 bits, by taking a 7 bit integer and doubling it. When this gets multiplied and then divided by the alpha value, those bits should be unchanged.
|
|
|
Logged
|
|
|
|
Impmaster
|
|
« Reply #4086 on: May 08, 2013, 01:33:38 AM » |
|
This all sounds so complicated.
|
|
|
Logged
|
|
|
|
Pishtaco
|
|
« Reply #4087 on: May 08, 2013, 02:03:31 AM » |
|
This all sounds so complicated.
Yes. The idea above isn't working, I dunno why. Maybe pixelbender likes treating colours as floats so much that anything that relies on them behaving like integers is doomed. Another option is to store the transform as a very low-resolution bitmap, ~256x256, so that I can store a coordinate as a single channel, and sample from this bitmap with linear interpolation to smooth things out. However my warp has a discontinuity in it, which might look odd smeared out over several pixels. I suppose I should try it. Edit: actually, scratch that suggestion. Parts of the transformed image are meant to line up with the original one, and having everything live on a 256x256 grid isn't going to work.
|
|
|
Logged
|
|
|
|
Pishtaco
|
|
« Reply #4088 on: May 08, 2013, 05:03:42 AM » |
|
Ok, I got this working. I gave in and used two bitmaps to store coordinates, one for x and one for y. Unfortunately, a little bit of pixelization and noise creeps in, and since I'm iterating the warping it just gets amplified and ends up looking like crap. So no more caching for me. (The project is this fractal doodling program, btw: http://forums.tigsource.com/index.php?topic=33260.0) Next possibility for optimization - if we happen to be calculating integral complex powers, rather than arbitrary ones, then we don't need the trigonometry and could use a faster shader ... Edit: Turns out the caching does work cleanly, I had just typed an r where I should have had a b.
|
|
« Last Edit: May 08, 2013, 02:30:50 PM by Pishtaco »
|
Logged
|
|
|
|
Dr. Cooldude
Guest
|
|
« Reply #4089 on: May 08, 2013, 02:24:12 PM » |
|
I'm finally motivated to work on my game! ... right when I'm extremely sleepy...
|
|
|
Logged
|
|
|
|
kamac
|
|
« Reply #4090 on: May 08, 2013, 02:31:33 PM » |
|
I'm finally motivated to work on my game! ... right when I'm extremely sleepy... I am so tired I am so tired I am so tired I am so tired I am so tired I am so tired I am so tired I am so tired I am so tiredSleep is for the weak. I am so tired I am so tired I am so tired I am so tired I am so tired I am so tired I am so tired I am so tired I am so tired
|
|
« Last Edit: May 08, 2013, 02:46:04 PM by kamac »
|
Logged
|
|
|
|
Dr. Cooldude
Guest
|
|
« Reply #4091 on: May 08, 2013, 02:49:05 PM » |
|
I'm finally motivated to work on my game! ... right when I'm extremely sleepy... I am so tired I am so tired I am so tired I am so tired I am so tired I am so tired I am so tired I am so tired I am so tiredSleep is for the weak. I am so tired I am so tired I am so tired I am so tired I am so tired I am so tired I am so tired I am so tired I am so tiredheh, i'm not even lying when i say that i'm so tired right now that my legs feel like theyre going to collapse oh god i can't even write now, goodnight
|
|
|
Logged
|
|
|
|
|
Impmaster
|
|
« Reply #4093 on: May 08, 2013, 08:45:47 PM » |
|
What is that code? Doesn't look like anything to me, but then again, I am a lowly Java programmer...
|
|
|
Logged
|
|
|
|
Eigen
|
|
« Reply #4094 on: May 08, 2013, 10:06:56 PM » |
|
AsAssesretritoino nf afialielde:d :C aCnannonto tl olaoda da na no gogg gf rformo mt hteh em emmeomroyr yb ubfuffefre r CoCnodnidtiitoino ni si sf aflasles:e :e rerrorro r= == =0 0 FuFnucntcitoino:n :o noLnoLaoda di ni n/ U/sUesresr/st/otmommamsaos/oD/EDVE/Vd/odjooj/os/rscr/cS/oSuonudnBduBfuffefre.rc.pcpp p@ @ 111188
What is that code? Doesn't look like anything to me, but then again, I am a lowly Java programmer...
That's concurrent logging. Just write a wrapper function for your log/print call and surround it with a mutex. That way two or more calls don't get mixed up. In SFML it is as simple as this: void myLog(const char * msg) { logMutex.lock(); printf(msg); logMutex.unlock(); }
|
|
« Last Edit: May 08, 2013, 11:22:36 PM by Eigen »
|
Logged
|
|
|
|
_Tommo_
|
|
« Reply #4095 on: May 09, 2013, 02:04:30 AM » |
|
Yeah I know... but I didn't do it because it's interesting to know that the errors happens at the same exact times, in fact it lead me to find the bug :D Also, by design you should not be printing stuff from the background threads.
|
|
|
Logged
|
|
|
|
Dr. Cooldude
Guest
|
|
« Reply #4096 on: May 09, 2013, 03:19:43 AM » |
|
A bit off topic, but...
|
|
|
Logged
|
|
|
|
gimymblert
|
|
« Reply #4097 on: May 09, 2013, 10:46:52 AM » |
|
2^12 ... what a waste of bit here, that's 4 unused
|
|
|
Logged
|
|
|
|
Quarry
|
|
« Reply #4098 on: May 09, 2013, 10:59:24 AM » |
|
You use the rest for the alpha channel; 4a4r4g4b
|
|
|
Logged
|
|
|
|
Will Vale
|
|
« Reply #4099 on: May 09, 2013, 06:58:23 PM » |
|
Also, by design you should not be printing stuff from the background threads.
I dunno, I found the two most useful tools for debugging SMP/AMP/MT issues were: 1) Being able to log (whole lines!) from any core/thread, with the core/thread ID prepended to the log message. 2) Being able to quickly switch any async code to run synchronously instead. A lot of multithread/multicore problems are hard to debug (either because they're really wide, or because they're timing dependent) so it's easy to capture some good log spew and pore over it to spot the issues. Plus being able to run code synchronously without recompiling makes it easy to spot if an issue is caused by the asynchronicity or not. YMMV, naturally Will
|
|
|
Logged
|
|
|
|
|