[QUOTE=slime73;40250645]Program files only partially exists on OS X, is several different places at once in Linux, [b]is two separate places in Windows depending on OS and architecture[/b], and is not available for access at all on iOS.[/QUOTE]
Just a quick interjection. It's actually four places.
With UAC, "Program Files" (and its x86 variant) are supposed to only contain static files and shouldn't be modified by applications without elevated rights. If a program wants to store modifiable data in its so-called program files, to enable backwards compatibility, a directory is automatically created in the user's directory (called "VirtualStore") that mimics in structure the program files.
[editline]12th April 2013[/editline]
You'll see lots of old games do this with their .inis and possibly save data
So, I started working on the OpenCL renderer again (After putting off getting shadowing done for a million years). I realised that a spherical projection is clearly a terrible idea - to achieve the same resolution as a cube map, you'd have to have a buffer somewhere abouts the same size as a cube map (well not really, but thereabouts), and there are a few problems with (such as it being atrocious quality, and the irritating seam that i couldn't be bothered to fix)
With the main slowpoint being memory accesses not processing power, it doesn't make sense to use a spherical projection (which makes inefficient use of the available memory)
Another nice point is, i was very much anticipating having to implement multiple lights. As far as i was aware, the engine only had 1 hardcoded light in it. I think the best surprise i have had so far today is finding out that i actually have support for multiple lights, with positions, rotations, and shadow-casting flags, and an expanding gpu-memory buffer every time you add a new light in (the worst thing about OpenCL is probably allocating and passing memory)
With cube mapping as well, i can simply adapt the existing function to rotate triangles into screenspace and draw their depth onto the depth buffer, remove the part that means that valid triangles are copied into a separate buffer (should probably do this anyway because the speed gain doesn't seem to outweigh the memory access), and then rename the arguments a little bit (and allocate memory for the lights which cast shadow)
With that done (was surprisingly painless, though untested, and I just realised it could be easily made to run faster), all i have to do now is allocate the cube-memory for lights which cast shadows, clear it every frame, then pass it to my screenspace step, rotate each pixel into the cubemap, and check the depth against the cube map depth for every light on screen.
[QUOTE=Map in a box;40250711]It was just an example. Don't single out one thing to prove me wrong, because the uses are unlimited. Why is there a filesystem in the first place if you can't read files created by other programs?[/QUOTE]
Don't call me names!!!
[QUOTE=slime73;40249970]What other directories would those be? Would they be used in the sort of situations LÖVE was designed to be used in (multi-platform games)? Do they even exist on all platforms? Would the API still be nice and consistent if they were easily accessible? Can sandboxed environments (iOS, Android, Mac App Store, Windows 8 store) access those directories?[/QUOTE]
Wrote a mod for Mari0 which allowed custom hats. Would have been nice to allow them to import images without copying them to the love/package directory first. I however do completely see why it is sandboxed. Also android applications still allow you to access the sdcard and some of the internal memory.
[QUOTE=cani;40251205]Wrote a mod for Mari0 which allowed custom hats. Would have been nice to allow them to import images without copying them to the love/package directory first. I however do completely see why it is sandboxed. Also android applications still allow you to access the sdcard and some of the internal memory.[/QUOTE]
Yeah, I think there is still room for improvement with love.filesystem's directories and it's especially noticeable when mods are involved.
[QUOTE=ThePuska;40250862]Just a quick interjection. It's actually four places.
With UAC, "Program Files" (and its x86 variant) are supposed to only contain static files and shouldn't be modified by applications without elevated rights. If a program wants to store modifiable data in its so-called program files, to enable backwards compatibility, a directory is automatically created in the user's directory (called "VirtualStore") that mimics in structure the program files.
[editline]12th April 2013[/editline]
You'll see lots of old games do this with their .inis and possibly save data[/QUOTE]
I actually ran into a lot of problems with this when I was doing my Lego Racers hacking a while back, since my modified game assets were being thrown into the VirtualStore but the game itself was reading from the (unmodified) Program Files.
Working on a befunge editor
[t]http://puu.sh/2yrwB[/t]
Edit:
I added (most of) the actual interpreter which only took a few minutes and it actually runs now. I think I'm going to integrate the output into the window itself
Also a slightly more compact program
[t]http://puu.sh/2yt1f[/t]
Edit:
I added the output at the bottom and fixed some bugs. I still need to write input stuff.
[img]http://puu.sh/2ytBg[/img]
Also I just realized that the thread is pretty much over
[QUOTE=ZenX2;40252063]Also I just realized that the thread is pretty much over[/QUOTE]
whats the post limit on these threads?
made small changes to the lava particles
[video=youtube;oTFaxtv3DUY]http://www.youtube.com/watch?v=oTFaxtv3DUY[/video]
p.s. it's so slow (~16fps) because i used the android emulator to record :(
Sorry, you need to Log In to post a reply to this thread.
