Advertisement Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

2663 Excellent

About jwezorek

  • Rank

Personal Information


  • Twitter
  • Github

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Recently I looked through a bunch of triangular cellular automata in which each (1) uses two states, (2) uses the simple alive cell count type of rule, and (3) uses the neighborhood around a cell c that is all the triangles that share a vertex with c; that is, the 12 shaded triangles below are the neighborhood around the yellow triangle: These cellular automata have state tables that can be thought of as 13 rows of 2 columns: there are 12 possible non-zero alive cell counts plus the zero count and each of these counts can map to either alive or dead in the next generation depending on whether the cell in the current generation is alive or dead (column 1 or column 2). I looked at each of the 4096 cellular automata you get by filling the third through eighth rows of these state tables with each possible allocations of 0s and 1s and letting all other rows contain zeros. A handful of these 4096 feature the spontaneous generation of gliders but one rule is clearly the triangular analog of Conway’s Life. I have no idea if this rule has been described before in the literature but it is the following: On a triangular grid If a cell is dead and it has exactly four or six vertex-adjacent alive neighbors then it alive in the next generation. If a cell is alive and it has four to six vertex-adjacent alive neighbors, inclusive, then it remains alive in the next generation. Otherwise it is dead in the next generation. The above exhibits the glider shown below and the “bounded growth” that characterizes Conway’s Life. (To see this rule in action see my external blog on which I have it running in an embedded web CA app) Tri Life gliders are slightly rarer than in Conway life because they are bigger in terms of number of alive cells in each glider “frame” but do show up randomly frequently.
  2. Nvm. I just copied Matrix.cs, Vector3.cs, and Vector4.cs from Monogame, and search and replaced float with double.
  3. Hey does anyone know of a library for C# that lets me do transformations on 3D points where everything is doubles not floats? Currently I'm using XNA/Monogame which has what I need but only for floats. I need things like vector.Transform(Matrix), Matrix.CreateTranslation(...), Matrix.CreateFromAxisAngle(...) etc. -- the normal stuff. I dont need any graphics calls: this is for a receational math / researchy thing not a game.  There is a library for C# called Math.Net Numerics and Math.Net Spatial but "Spatial" has like nothing in it. The numerics one will get me matrices but they didnt write all the convenience routines for the geometric interpretation of vectors and matrices as far as I can see. I am wondering if someone has this up on github somewhere on top of Math.Net but havent found anything.
  4. Which is best? I read in this old post and elsewhere that boost::signals is shockingly slow so that seems out. Does anyone know if Sneftel's code from the above link has been updated anywhere? (the link is 10 years old). Stackoverflow also mentions  libsigc++, but again that post is kind of old. Thoughts? Are there other ones to consider?
  5. Unfortunately, quiet a bit of it, it's a heavily custom UI, lots of custom controls, places that customize down at the win32 level -- old desktop application, and lots of places where business logic is mixed in with the GUI. There was an initiative to port to WPF about two years ago but it failed basically. Here's the thing though: at this point is WPF even necessarily better supported than WInForms? I'd argue that WinForms might actually be more stable *because* it is older; whereas, WPF is now in maintenance mode too but in my opinion a lot of it never fully matured. I mean like at another job I remember there being performance problems when trying to put 100,000 or more items in a WPF listview unless you made it virtual etc. seemed to me the kind of stuff that would have been fixed if MS was still 100% behind WPF as their flagship desktop platform.
  6. I'm working on a 2D game framework that is currently on top of SFML. I want to add a feature to my framework in which the user can select at start-up between what the framework will refer to as "coordinate systems": (1) TopLeftOriginDescendingY, (2) BottomLeftOriginAscendingY, or (3) CenterOriginAscendingY.   The idea being that SFML uses (1), all flavors of cocos2d-x use (2) and I personally think (3) makes a lot of sense because of philosophic alignment with mathematics and makes sense practically for handling multiple screen size and aspect ratios.   I figured this would be an easy thing to do because I could just roll into my "coordinate mapping matrix, which transforms "logical coordinates" into screen coordinates another transformation that handles the 3 systems above in cases (2) and (3) doing a scale by (1.0, -1.0) to flip the vertical axis because SFML uses (1) by default. The problem with this, I realize now, is that scaling by (1.0, -1.0) will cause all of my sprites to be upside down. I could handle that by flipping the textures in memory if in inverted-y modes but it seems kind of inelegant. I am planning to eventually break my dependency on SFML and re-implement the part of SFML I am using directly on top of OpenGL so am now leaning towards not doing  "coordinate systems" right now but implementing it when I remove the SFML dependency.   My question is basically is there a more elegant way to do what I want to do in SFML that I am not seeing? Perhaps using the sf::view class which I havent touched before? If not am I right in assuming that allowing this feature in a direct OpenGL implementation will  admit a solution that does not involve me flipping texture raster lines?
  7. Can't just switch to WPF because of a 100,000 lines of legacy code. This is for my day job ... some people are working on updating our UI by reskinning with custom controls in WinForms. Multi-DPI mostly works modulo problems. A big problem is VS Design View related. Sometimes when you just open a dialog VS will modify it to make it use the DPI you have opened it at or something like that. Not sure exactly ... just general diffiulties probably resulting from the fact that the last time anyone at Microsoft touched any of this stuff 90% of computers ran at 96 DPI. Anyway usually there are competing products for everything, was surprised my Google Fu was not revealing even a single drop-ip replacement for the WinForms Forms editor so asked here.
  8.   Actually not ... looking for one that sucks less. specifically  Easier to select/navigate nested layout panels better handling of DPI issues e.g. allow toggling between DPIs in design view. MS's product is fine but seems like it hasnt been updated in ages and does have some problems. I can't get specific about the DPI stuff but it just feels like there are bugs there.
  9. ... does anyone know if such a thing exists?
  10. jwezorek

    copy/paste crossplatform

    I think you need to be a little more specific about what you need to do to get a good answer. That is, 1. You want to "paste a number" from where to where e.g. from the clipboard to an existing native window that you don't control? 2. Which platforms do you need to support? 3. If all you need to do is paste why are you asking about "open[ing]" a GUI? So I'm not sure how to answer, but if all you need to do is paste from the clipboard in any case I find it hard to believe there is going to be an easier way then implementing such functionality yourself on the platforms you want to support and abstracting the separate implementations in some platform-independent wrapper (the details of which will depend on the language(s) involved).
  11.   The trouble with value semantics is what to do if the thing that you want to pass around needs to use olden days C++ polymorphism. If you pass around an object by value you have to know what that object is; if all you have is an interface to it, you have to pass around some flavor of pointer. You could wrap that olden days C++ polymorphism in various ways, to have an object that will do polymorphic dispatch but that you can treat like a value. To do that "idiomatically" is easy, it's called a shared_ptr<T> where T is a base class, which is why code from 10 years ago had boost::shared_ptrs everywhere. Before people got fancy about talking about the semantics  of ownership people were treating shared_ptrs as a value semantics wrapper around banal C++ polymorphism.   You can have value semantics and do polymorphic behavior via composition rather than inheritance, but this opens its own can of worms to framework writers. In the same way in this thread people are saying "dude, just use raw pointers" you find yourself saying "dude, just use inheritance." It's a trade-off like everything else.   In this example, spritesheet->createSprite("name_of_a_sprite_in_the_sheet") is generating a concrete object of type Sprite, but another way you could get a sprite is by defining your own class SpaceshipSprite that inherits from Sprite and calls a constructor like Sprite::Sprite(spritesheet, "name_of_a_sprite_in_the_sheet") from its constructor but also inserts child sprites for the spaceship's thruster flame or whatever in the constructor. If you want to then pass SpaceshipSprite to all the places where you could pass a Sprite, by value not by any flavor of reference, then all those places will have to be parametrized on type which will turn your turn your framework into a header-only or header-mostly framework and mean that you can't shield users of the framework from its dependencies, the hardware abstraction layer it uses etc., by statically linking to those dependencies and using them intenally. You can't link to anything, you're not code, you're a template.
  12. so then in this case, the register functions should take raw pointers or references to the actor being registered, right?
  13.   It shouldn't, though.   unique_ptr carries sole ownership wherever it goes. If you're returning it from the function, then you've already transferred ownership away from whatever had it before (in this case the sprite sheet), which is probably not what you intended.   This came up in another topic recently. Basically, don't pollute your interfaces with unique_ptr/shared_ptr/etc. unless you're dealing with ownership semantics. Otherwise, keep it simple with raw pointers or IDs.     Sprite sheets here do not own sprites. It's a wrapper around a texture packed with sprite frames and metdata needed to grab a given sprite frame i.e. its location in the texture. Maybe the name is bad, could be a SpriteAtlas and createSprite maybe. But in any case it is like a factory not a container. I think it should return unique_ptrs because the semantics of the whole thing are that sprites should always have one and only one owner.
  14. I'm working on modernizing an old 2D game engine in C++ that I started in (i think) pre-C++11 / C++14 days.    It uses a scene graph/ sprite node tree, whatever you want to call it, that had been a tree of boost::shared_ptrs, but I want to change it to use std::unique_ptrs. My reasoning is that unique ownership of nodes by parent nodes and unique ownweship of the top level node by the scene object is what actually makes sense. I think I had been using shared_ptrs because at the time I did everything with shared_ptrs.   Everything is fine however one thing that is definitely awkward is the codebase's concept of registering an object to recieve a callback. The way it works is if you want some sprite to receive an update on each iteration of the game loop you register an update function with the parent scene, likewise for keyboard events and other user input events.    so there's member functions like   void Scene::scheduleUpdate(const std::shared_ptr<Actor>&, const UpdateHandlerFunc& func);   void Scene::registerKeyEventHandler(const std::shared_ptr<Actor>, const KeyEventHandlerFunc& func);   ... to do this, which will store the functions in a hash table in the scene using Actor*'s as keys.   Now the trouble is that a common usage pattern would be something like the following, when initializing a scene would be to have some code like the following (the this's her   auto spaceship = sprite_sheet_->getSprite("spaceship"); //this returns a shared_ptr // code to intialize spaceship... this->addActor( spaceship ); // "this" here is a scene this->scheduleUpdate(spaceship ,      [&](const std::shared_ptr<coy::Actor>& actor, float dt) {          actor->updateShip(dt); //or whatever     } );   the trouble is if I make getSprite return a unique_ptr which it should then the call to addActor would be a addActor( std::move(spaceship) ) which means I'd no longer have a pointer to spaceship to scedule an update to. I could change the order of those calls but youd be scheduling an update to sprite that is not (yet) a child of the scene, which seems bad.    I could make addActor be optionally passed an ID that can then be used for doing things like scheduling updates?   Or I could get rid of the whole notion of scheduling updates and registering receivers of keyboard events, but I definitely don't want to replace it with havinng updatees need to inherit and override an  virtual update(float dt) member function because I am trying to keep from forcing users of the framework from having to necessarily do inheritance as much as possible.    But I'm not sure what to replace it with: UpdateHandlerFunc et. al. member variables in Actor? 
  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!