Jump to content

  • Log In with Google      Sign In   
  • Create Account

davepermen

Member Since 31 Mar 2000
Offline Last Active Dec 18 2014 04:38 AM

#5191800 Mac or PC - Really, this is a programming question.

Posted by davepermen on 08 November 2014 - 10:45 AM

Surface Pro 3, docked. Windows 8.1. Visual Studio 14




#5139993 DirectX 12 Announced

Posted by davepermen on 18 March 2014 - 07:22 AM

I hope it has proper WinRT bindings/projections so one can use dx directly from c#. right now, casual gamedev isn't as fun as in xna days.

 

oh, and i hope for vr support. like steam engine has it now. so i can put my oculus to good use and know future vr headsets will work, too.




#5133247 What can you use C# for?

Posted by davepermen on 21 February 2014 - 07:26 AM

I use it for gamedev (xna/monogame + xamarin basis == my game can run on pc, win8 tablets, windows phone, iphone/ipod, ipad, android)

i use it for tools (wpf)

i use it for wp8 and win8 apps.

i use it for server side code (mostly nancyfx based, on asp.net or owin).

i use it for local windows services (typically nancyfx, selfhost)

i use it for tiny tools (command line apps that do something quick for me)

i use it for realtime game server communication (through signalr)

i use it for raytracing (no simd and no gpu == comparably slow, but i just love doing it).

 

so i use it for anything except web-front-end, where i use html5, css3, javascript (es5).

 

i could use it on linux and osx (mono), and even on tiny controllers like arduino-thingies (.net micro framework).

 

i could use it to write (most of) my own os, if i ever have too much time :)

 

so it's very flexible.




#5132413 Tricky Visual Studio 2013 issue

Posted by davepermen on 18 February 2014 - 01:13 PM

depending on what's how your networks are setup, remote desktop into your home machine might be an idea. it will most likely be very slow, but it would be an option. legal issues aside :)




#5115084 Looking for the best Graphic Library to use with C# (No Xna Please)

Posted by davepermen on 07 December 2013 - 06:32 AM

I use monogame myself right now. There's no need to find documentation about it, as it really just works like xna.

 

The only thing lacking is the content pipeline, so you have to load your stuff yourself. But in case of a 2d situation, That's a one-liner thing anyways.

 

SharpDX is cool, too. Monogame uses it, too :)




#4999919 What's your take on protected variables?

Posted by davepermen on 11 November 2012 - 09:04 AM

What's your take on protected variables?

In the context of c++, it seems most experts (Scott Meyes, Herb Sutter) think is not a good idea. I don't agree. In fact, some languages, for example Ruby, have only automatic protected variables.
It seems silly to make a 'setter' and 'getter' functions for a variable when the derived object is employ in terms of "is-a". Also, making 'setter' functions opens the variable to be manipulated from outside the object! Of course, one could make in the 'setter' protected, but isn't that 'running in a loop'?

Please, discuss.

EDIT:

Let's say I have:

[source lang="cpp"]class Shape{public: virtual void CalculateArea();private: //private! int x, y; int width, height;};class Rectangle : public Shape{public: void CalculateArea(){ /* I need width and height to calculate, but can't access it. What can I do? */ }};[/source]
If I make 'getters' for Shape class:

[source lang="cpp"]class Rectangle : public Shape{public: void CalculateArea(){ get_width(); //isn't this silly, as width is a fundamental part of Rectangle //also, now everyone knows my width! }};[/source]


the problems with getters and setters is, people take them too literally.

they make a get and set for each variable, allowing users to, again, invalidate state.

your rectangle class needs left, right, width, top, bottom, height, area, aspectratio, etc to be publically accessible. and none of those getters/setters/whatevers should make it possible to have an invalid rectangle, ever.

set_width() can check if you enter a negative width, and prevent it. set_right can check if your right is more left than your left, and prevent it. and vice versa.

it's not about making methods that directly expose your variables in public. if you want that, use public directly. getters and setters is about NOT exposing anyting directly. aobut making SMART getters and setters. in that case, about making a rectangle ALWAYS a rectangle. not something that has negative space, or what ever.

and as having an object valid at all time is very important, public variables are dangerous. as are protected ones.

but forget about getters and setters. don't write a car that has get_position and set_position. write a car that can drive(), turn(), break() and return current_position(), current_orientation() instead.

if you expose your variables directly, you did not understand the idea of getters and setters.


#4999916 The Singleton Pattern: To be or not to be [used]?

Posted by davepermen on 11 November 2012 - 08:56 AM

METADATA:

There are many times when a program needs to store and reference data that is a result of processing and that can be used again. How will you store metadata? I like to use singletons for structural/constant data/flags/metadata(temporary) instances, when the complexity of creating new instances and having it loading its data from something/somewhere doesn't worth as simply acessing it straight like cache of processors is used and Windows Registry (always in memory).

I just use an ordinary class for this. And if at some point i need multiple different resources, I can just do that. If i don't, I don't. That's the point: LIMITING YOURSELF doesn't help you later. It will BLOCK you later. Without ever having given you any gain. You want just one: Instanciate just one. You want global access? Make it a global. Don't try to hide it behind some fancy terms. Be honest to yourself.


#4999265 The Singleton Pattern: To be or not to be [used]?

Posted by davepermen on 09 November 2012 - 06:55 AM

the streering wheel example shows that some people don't understand what a class is for, and what an object is for.

class SteeringWheel {
}

class Car {
    SteeringWheel steeringWheel;
}

classes are not what defines how many exists of something. that's the objects job.

if a singleton would fit my needs, i would use it. but it NEVER ever did. it's just a) limiting and b) making code look ugly. and, most importantly, c), it NEVER makes sense.


#4961290 Does any interest in the Go language still exist?

Posted by davepermen on 20 July 2012 - 06:28 AM

heard that from too many languages. but, we'll see.


#4956283 Global variables in comparison to #define

Posted by davepermen on 06 July 2012 - 04:53 AM

define is just a text replace, and does not care about the language. that can lead to some interesting abuses, and some interesting uses (the header include once thing). other than that, use language features, as they don't want to bite you in the back.

like #define max did all the time for me...

if you don't plan to ctrl-r replace-all-text, don't use #define.


#4948186 Use Qt, something else, or roll my own?

Posted by davepermen on 11 June 2012 - 09:30 AM

I think szecs' response is a better answer than I could personally give to your post, so I will refer you to his post, but I just want to add that the main things I want to learn about are:

-Managing scene objects
-Building an optimized resource caching system
-Building a robust scripting system

I know what your response is going to be, "No! You're crazy! Use an engine!". That's fine, do what you want for your projects, but my decision is made on this, and I'm actually really enjoying building my own system from scratch. I like working on low level systems. Making high level game logic isn't the only thing that interests me. Anyway, thank you for the reply, and best of luck.

No, I don't say "Use an Engine". I say MAKE GAMES. you can't learn to properly manage scene objects if you don't have a reason to manage them in the first place. You don't learn about wrong design if you don't use your design.

Create your own engine, but do it BY MAKING A GAME.

I never said, and never will say, use an engine. That's NOT the point. But you can not build a good car if you never ever testdrive it. You can't built a great pc together if you never ever turn it on.

Use your engine. Create games. And let the engine evolve while doing so. You will learn MUCH MORE. Because an engine is a tiny tiny tiny part of the logic that a game requires. And if you make games, you will have to learn ALL the logic. That will help you, learning much more (massively much more), and your engine, not falling apart on the tiniest first try-out.


#4926032 Alternative to singleton

Posted by davepermen on 28 March 2012 - 10:28 AM

And there you see for yourself the wrong way of thinking that is the singleton drug: See all the bad things.

Guess what? For multiTOUCH, that mindset had to change (example in win8: with one finger you chose a tile, with the other you move the full screen below that tile to quickly bring it to a new place). so would it had to change for multimouse, obviously.

and yet, all the games and apps on multitouch devices don't HAVE to care about multitouch if they don't want to. but they CAN

and THAT, sir, is the POINT.

SINGLETONS RESTRICT POSSIBILITIES.

THAT
IS
NEVER
A
GAIN

NEVER.

i gave you multiple examples by now, and yet you just don't get it. it's like someone who smokes who just can not understand what to do if he would quit smoke, as so much would change to the worse (no breaks all the time, because, what to do then? getting fat, because one eats more, etc). you know singletons are bad, yet you don't even try to just work and think without them. try it.


#4925679 Alternative to singleton

Posted by davepermen on 27 March 2012 - 08:56 AM

If you ever used a 3d app like 3d studiomax, or photoshop, you would have loved more than one mouse.

The fact that you can't even imagine the possibilities (pinch to zoom with something as accurate as a mouse? a dream. same for rotation and stuff, 3d modelling in general) just shows how far a singleton can restricts ones mind.

the example i gave in an older post was about rendering to multiple contexts in the early days of opengl to do rendertotexture style stuff. as opengl is essentially a huge singleton, i never could grasp myself around it, i was too used to that "statemachine that just does everything for me". and that's exactly what singletons evolve into: huge "everythings" that then make you go blind on possibilities you're missing.


the other example (i think in the 'are globals bad' topic) was the player singleton. a lot do that, imagining there's just one player. but even in a singleplayer, that's not true. you have enemies. imagine them being able to use the same physics, the same movements, the same weapons, the same cars and planes and stuff that you do? they are a player, just one with a different "controller" behind it.

once you move away from the player singleton, suddenly you can be anything in the game, so you could start to mind-control other characters, etc. or they could use your vehicle when you don't look for it. suddenly, the game evolves while you develop it into something much bigger.

singletons always block you at the most important part: where you're thinking. because while coding, that part is active: your brain. and if the code does not allow you to do stuff, you won't even imagine that stuff anymore.



and yes, touch and mouse are not the same. hence multitouch does not replace the power of multiple mice. i feel this the most when i'm producing music. to do it accurately, you can't use touch. you need a mouse. but more than one mouse would allow so many features we're used from multitouch, it would be great.


#4925635 Alternative to singleton

Posted by davepermen on 27 March 2012 - 05:38 AM

a singleton in mostly every os of today: the mouse.

if it wouldn't be, we could plug in more than one mouse and use more than one cursor (similar to multitouch) since years in every os. and heck yes, i would. sadly, at some point we got limited to only one device ever, as no one ever needs more than one cursor. and the whole os' got designed around it.

now that we can have multitouch, the os' are still not designed for it (at least win7). the result: i can not, for example, drag multiple windows independently around the desktop at the same time.


it's a simple example of potential that was there since years and never got exploited just because we where all fixed on "there can be only one".


#4925631 Avoiding Global Variables

Posted by davepermen on 27 March 2012 - 05:19 AM


I think the moral of the story is "making assumptions, especially implicit assumptions, is really stupid."

Or something to that effect.


I'm seeing assumptions from both sides, one that you will need more than one of these objects in future, and the other a simplifying assumption that chances are you won't.

What of the simplifying assumption that this class doesn't support multithreading? Or do I have to support mulitthreading for all classes because if I scale the system up I will likely need that one day? I just don't understand why everything has to be a black and white/all or nothing proposition.

Working with the cryengine SDK recently, and had a bit of a laugh seeing all the globals and #defines in there. But you know what, the world didn't end, I was able to get in there and update the code without a lot of hassle. Sure, it's no ideal, but answer me this - would cryengine be a better product had it been developed using software design best practices (under the same budget/time constraints). In my estimation, they wouldn't have a product today had they attempted to take this path.


If you work without globals and shared locals and stuff, you don't have to prepare for your classes to work with multithreading. they will just work. obviously, you have to write the multithreading stuff correctly, but you don't have to change anything in the class, or know any implementation details that you have to workaround then.

that's kinda the point: if you write code without globals and singletons and that crap, the code is more simple to write, and as a bonus, much simpler to use in future, nonpredicted scenarios.

just stop doing it and you'll notice it.




PARTNERS