[QUOTE=WTF Nuke;48162222]I said they DO know their size. It's just implementation based and not revealed to the user. What I mean is only new[] points know their size, not just any old pointer. So if you decayed a stack array to a pointer, it wouldn't know its size.[/QUOTE]
But that's not true, the operating system internally knows the size of any plain old pointer. If it didn't you wouldn't be able to free memory OR the free function would need an additional size argument.
[editline]10th July 2015[/editline]
It's just no operating system actually has an API function that returns the size of a pointer.
Wait so let's say I did this:
[cpp]void pass(int *);
int a[3];
int b[5];
pass(a);
pass(b)[/cpp]
Internally, if pass could print the size of the pointer passed to it, it would print 12 and 20 or something along those lines?
I assumed the stack just contained the size of the variables rather than each individual variables size, but I don't know.
[QUOTE=WTF Nuke;48162342]Wait so let's say I did this:
[cpp]void pass(int *);
int a[3];
int b[5];
pass(a);
pass(b)[/cpp]
Internally, if pass could print the size of the pointer passed to it, it would print 12 and 20 or something along those lines?
I assumed the stack just contained the size of the variables rather than each individual variables size, but I don't know.[/QUOTE]
Arrays allocated on the stack don't store their size since everything in a function's scope is popped at once.
Things that drive me nuts in Unity: Orthographic cameras don't work with deferred lighting. I just spent like an hour trying to figure out why deferred decals were not working...oops.
[QUOTE=ECrownofFire;48162438]Arrays allocated on the stack don't store their size since everything in a function's scope is popped at once.[/QUOTE]
That's exactly what I thought, which brings me to my point of why you can't get the size of an array.
[QUOTE=ruarai;48162515][IMG]http://i.imgur.com/IR1dQYc.png[/IMG]
I've seen similar programs but none that fill this specific niche.[/QUOTE]
The low complexity backgrounds get a little bit janky
[QUOTE=WTF Nuke;48162222]I said they DO know their size. It's just implementation based and not revealed to the user. What I mean is only new[] points know their size, not just any old pointer. So if you decayed a stack array to a pointer, it wouldn't know its size.[/QUOTE]
Full disclosure: Only read the first sentence. Sorry
I also only read the first sentence, where's my apology?
needs to be way stronger
[editline]10th July 2015[/editline]
right now it just looks like compression artifacts
oh my god that is the funniest fucking clip from iasip
Someone should train deep dream on porn, then run it on not porn
Instant R34 of any image
I made a loading screen today.
[t]http://i.imgur.com/hennhrt.png[/t]
Now let me tell you about Unity's wonderful asynchronous scene loading mechanism:
If you choose to suspend the actual scene activation via AsyncOperation.allowSceneActivation so that it requires a manual activation after loading is done, something interesting happens to the progress field included with the AsyncOperation instance.
After first testing my loading code, I sat staring at it for a good ten minutes, wondering why the fuck my progress bar wasn't reaching all the way when the scene finished loading. I checked the scaling factor, it was fine. I checked to make sure nothing was freezing the thread, and nothing was. But the scene [I]was[/I] loaded, so I dumped the AsyncOperation.progress value to the console just to make sure.
It stops at [B]90%[/B]. Unity what the fuck?
So now, instead of doing the logical thing and checking if the progress is 100% before activating the scene, I have to check if it's at 90%.
If someday after I'm dead and gone, someone reads through my code and sees that, they are going to wonder whether I was fucking insane.
[QUOTE=Berkin;48163269]wonder whether I was fucking insane.[/QUOTE]
[img]http://u.rtag.me/p/Jafy51.png[/img]
[QUOTE=Ziks;48163184]Someone should train deep dream on porn, then run it on not porn
Instant R34 of any image[/QUOTE]
Point it at deviant art for instant OC.
[QUOTE=Berkin;48163269]I made a loading screen today.
[t]http://i.imgur.com/hennhrt.png[/t]
Now let me tell you about Unity's wonderful asynchronous scene loading mechanism:
If you choose to suspend the actual scene activation via AsyncOperation.allowSceneActivation so that it requires a manual activation after loading is done, something interesting happens to the progress field included with the AsyncOperation instance.
After first testing my loading code, I sat staring at it for a good ten minutes, wondering why the fuck my progress bar wasn't reaching all the way when the scene finished loading. I checked the scaling factor, it was fine. I checked to make sure nothing was freezing the thread, and nothing was. But the scene [I]was[/I] loaded, so I dumped the AsyncOperation.progress value to the console just to make sure.
It stops at [B]90%[/B]. Unity what the fuck?
So now, instead of doing the logical thing and checking if the progress is 100% before activating the scene, I have to check if it's at 90%.
If someday after I'm dead and gone, someone reads through my code and sees that, they are going to wonder whether I was fucking insane.[/QUOTE]
Isn't there a completion event you can use instead?
[QUOTE=SteveUK;48161428]Primitive arrays in practically every language are static. If you want something like a C# List<T> in C++, use a std::vector.[/QUOTE]
Some languages embed the size in the type of the array though, and let you take slices of the array if you want to pass it as a T[] rather than a T[size]. Which is honestly a much better approach. (D/Rust) come to mind, of which D treats statically-sized arrays as value types.
Allocation being static does not necessarily require you to starve the programmer of information, since the type information is right there!
But I digress, it's a historical artifact of C, so in C++ there's not much you can do except default to the STL :v:
Can deep dream be run in real-time or is it pre-rendered?
Pre rendered. Takes about 8 minutes per frame if you have great hardware.
Still training because I for some reason find it more fun to train then actually generate stuff.
Currently training it using every nsfw reddit
[QUOTE=Xystus234;48164106]Can deep dream be run in real-time or is it pre-rendered?[/QUOTE]
If you have a PC from 2030, sure you can view it in real-time.
-- automerge --
[QUOTE=cartman300;48162299]But that's not true, the operating system internally knows the size of any plain old pointer. If it didn't you wouldn't be able to free memory OR the free function would need an additional size argument.
[editline]10th July 2015[/editline]
It's just no operating system actually has an API function that returns the size of a pointer.[/QUOTE]
Unless i'm misunderstanding something I dunno what you guys are talking about. When you allocate memory through a general purpose allocator the size of it gets stored in some meta data and when you deallocate it, it gets looked up. Some allocators do allow you to look up that size independently. There's also a move to have sized deallocations also because generally the size of allocations can easily be recreated by the type and quantity allocated, or just stored elsewhere. And the size of a pointer is always the same as one another.
[QUOTE=Philly c;48164217]Unless i'm misunderstanding something I dunno what you guys are talking about. When you allocate memory through a general purpose allocator the size of it gets stored in some meta data and when you deallocate it, it gets looked up. Some allocators do allow you to look up that size independently. There's also a move to have sized deallocations also because generally the size of allocations can easily be recreated by the type and quantity allocated, or just stored elsewhere. [b]And the size of a pointer is always the same as one another.[/b][/QUOTE]
We were talking about the size of the pointer data, but now that you mention actual size of pointer; no, not every pointer size is the same. Function pointers on x86 machine can range from 4 up to 20 bytes.
Hey waywo, long time lurker here...
Me and my friend have slaved over another game in unity for the last god knows how long and have released it a few days ago.
[video=youtube;Qm-Qv2D9k1g]https://www.youtube.com/watch?v=Qm-Qv2D9k1g&feature=youtu.be[/video]
Its currently only on google play:
[url]https://play.google.com/store/apps/details?id=com.AvalancheGames.PixelDuck[/url]
but its also being verified to go onto the app store.
If the game feels a little empty, that's because were going for a update/feedback based approach.
we conceptualized/created a lot of features which are currently not in the game which we decided either needed more work or did not work with what else was in the game at the moment....
However, we are trying to take on-board all feedback and community support we can by updating existing content and/or inputting various changes and new content as fast and frequently as possible.
Content coming with the first update:
-New movement/jump buttons instead of joystick -> suggested by community
-randomised dungeons (hopefully do that in time)
-Less baby text/baby steps inside the tutorial levels -> suggested by community
-Ability to skip the tutorial (huzzar!)
-Various minor bug fixes
Content finished but currently unavailable:
-Crafting
-Monster manuals
-Over 100 other weapons and 50+ items you cant currently use
-Potions
-Magic
-Storyline levels(needs serious work)
-Bunch of other smaller things
Content Ideas for the future:
-Networked arenas
-Destructible terrain?
-Challenge levels
-Randomised weapons?
-Randomised enemys?
-Multiple character skins
-Achievement based unlocks
-Other various bits and bobs!
If you do decide to try it out, please let me know what you thought and if you have any suggestions for future/current content. :smile:
[QUOTE=cartman300;48164313]We were talking about the size of the pointer data, but now that you mention actual size of pointer; no, not every pointer size is the same. Function pointers on x86 machine can range from 4 up to 20 bytes.[/QUOTE]
Fair enough that was a bit too broad, and I obviously meant that it changes depending on architecture etc, but I would have thought that a larger function pointer is not really in the same category as just a normal pointer to any memory?
[QUOTE=Winner;48163015]i'm making a thing that filters videos through deepdream, iterations per frame based on the current volume
[vid]http://box.talkha.us/public/ias.out.mp4[/vid]
the wave variance algorithm needs some work, but... yeah[/QUOTE]
How do you do this sort of thing?
[QUOTE=ruarai;48163116]I've now fixed this.
Turns out the pixel art input is too clean - this is an issue I never had with noisy photography. There's now a threshold to how low the chance of a sample forming can be.
[IMG]http://i.imgur.com/5Lo1R3O.png[/IMG]
Now it's very nice.[/QUOTE]
First off: this is an awesome project, I'm not here to rain on the parade.
Pixel art isn't your endgame. The entire point of the medium is that you can use visual tricks to include more information in a small image than a camera would by very carefully placing the individual pixels. Cameras downscale from real life, but pixel art upscales from this imaginary psuedoworld. Upscaling it with a filter that doesn't take that into account really ruins the effect.
[QUOTE=UchihaItachi;48164374]Hey waywo, long time lurker here...
...
If you do decide to try it out, please let me know what you thought and if you have any suggestions for future/current content. :smile:[/QUOTE]
There's some great potential here, but I have some issues.
-There needs to be a start screen. Your game should never boot directly into gameplay.
-The intro 'cutscene' with your logo and old duck is way too long. I thought the game froze!
-The popup boxes need to display text faster than I can read them. That typewriter thing is usually more annoying than it's worth. The fact that you added "tap the text to make it go faster" in the tutorial shows me that you were already aware of this problem.
-Your entire tutorial should be one level long, not split up. Don't even point out that it's the tutorial, it's just the 'first level'.
-The jump trigger needs to be lower on the joystick. Like 20 deg instead of 45. As it is, I need to stop moving to jump. If that's the case it should be on a separate button.
-Your tutorial textboxes need to popup when you walk past them. Maybe have them be smaller and float above the sign in the game world instead of being a separate popup.
-Your "locked door" mechanic is way too complicated. There don't need to be buttons to "Open door" "use key" and "open door". Just have it show that it's locked, and have it pop open when walking past it if you have a key, with some obvious indicator that you've used the key.
-The pedestals need to move quicker.
-Unless there are more complicated weapons then the club that make better use of the joystick, then it should just be a button.
I suppose that the main thing is pacing. People on mobile platforms leave if the first 30 seconds isn't already holding their attention hostage. That means everything should be as snappy as possible.
I'm excited to see where this goes, I got a surprisingly dark-souls feel from the combat. However those other issues are too much up front. Fix those and you're golden!
Damn it all.. Almost had npm working.
[img]https://dl.dropboxusercontent.com/u/27714141/hacking-world4.png[/img]
That's probably the only built-in node module that I can't provide a wrapper for..
Should I write my own package manager instead? :eng101:
[QUOTE=voodooattack;48165798]Damn it all.. Almost had npm working.
[img]https://dl.dropboxusercontent.com/u/27714141/hacking-world4.png[/img]
That's probably the only built-in node module that I can't provide a wrapper for..
Should I write my own package manager instead? :eng101:[/QUOTE]
What exactly are you doing?
[QUOTE=Darwin226;48165957]What exactly are you doing?[/QUOTE]
A hacking game with real scripting. The scripts run in a sandbox on the server using a virtual file system built on top of mongodb, and their outputs are piped into the browser via socket.io.
Sorry, you need to Log In to post a reply to this thread.
