| 00:00:01 | ldlework | dom96: yeah I can't wait to ask Araq_ actually |
| 00:00:03 | ldlework | I'm curious |
| 00:00:29 | ldlework | he will probably say, write your own run and tell the library author to refactor their code into smaller more reusable parts |
| 00:00:31 | ldlework | or something? |
| 00:00:48 | dom96 | possibly |
| 00:01:02 | * | Trustable quit (Remote host closed the connection) |
| 00:01:04 | * | dom96 needs to get back to studying |
| 00:01:28 | dom96 | Excited to see dadren progress, keep me updated :) |
| 00:07:02 | * | gokr quit (Ping timeout: 246 seconds) |
| 00:12:56 | * | vendethiel quit (Ping timeout: 276 seconds) |
| 00:59:22 | ldlework | If I have a type A and I make a type alias of it B, how can I specify a type that covers them both? Like a proc parameter? |
| 00:59:55 | * | jaco60 quit (Ping timeout: 240 seconds) |
| 01:04:32 | * | desophos_ joined #nim |
| 01:06:46 | * | desophos quit (Ping timeout: 240 seconds) |
| 01:06:49 | * | desophos_ is now known as desophos |
| 03:06:08 | * | vendethiel joined #nim |
| 03:29:20 | * | vendethiel quit (Ping timeout: 246 seconds) |
| 04:22:00 | ldlework | Is there any kind of enumerate() like iterator such as there is in python |
| 04:22:05 | ldlework | that will return int, T |
| 04:35:38 | def- | ldlework: pairs for types where it makes sense |
| 04:36:01 | ldlework | yeah I have a list of scalars |
| 04:36:35 | ldlework | def-: check it out, tilemaps support: https://gist.github.com/dustinlacewell/00049efdfc5e65a332c0 |
| 04:38:57 | ldlework | now time for Tilesets, which bring together multiple Tilemaps |
| 05:44:57 | * | darkf joined #nim |
| 05:52:04 | * | ludocode quit (Ping timeout: 250 seconds) |
| 07:11:56 | ldlework | anyone bored? |
| 07:39:42 | * | darkf_ joined #nim |
| 07:41:30 | * | darkf quit (Disconnected by services) |
| 07:41:31 | * | darkf_ is now known as darkf |
| 07:50:47 | * | vqrs quit (Ping timeout: 246 seconds) |
| 07:52:30 | * | vqrs joined #nim |
| 07:59:19 | * | Demon_Fox quit (Quit: Leaving) |
| 08:07:16 | * | ludocode joined #nim |
| 08:12:49 | * | zepolen joined #nim |
| 08:13:51 | ldlework | Can I use types as values? |
| 08:16:02 | ldlework | If anyone is around I'd love some advice. |
| 08:20:07 | ldlework | bleh |
| 08:39:00 | * | NimBot joined #nim |
| 08:40:50 | * | zepolen quit (Ping timeout: 246 seconds) |
| 08:47:56 | * | yglukhov joined #nim |
| 08:50:26 | * | zepolen joined #nim |
| 08:52:58 | * | kas_ joined #nim |
| 09:00:46 | * | yglukhov quit (Read error: Connection reset by peer) |
| 09:01:22 | * | yglukhov joined #nim |
| 09:02:21 | * | yglukhov quit (Remote host closed the connection) |
| 09:15:29 | * | vendethiel joined #nim |
| 09:15:41 | * | yglukhov joined #nim |
| 09:20:04 | * | yglukhov quit (Ping timeout: 250 seconds) |
| 09:27:40 | * | HakanD joined #nim |
| 09:33:06 | * | awsteele joined #nim |
| 09:34:56 | * | yglukhov joined #nim |
| 09:35:03 | nsf | type A = ref object ... |
| 09:35:07 | nsf | type B = distinct A |
| 09:35:10 | nsf | var b: B |
| 09:35:14 | nsf | assert b == nil |
| 09:35:18 | nsf | fails to compile, is it expected? |
| 09:35:49 | nsf | I understand the main point of distinct is to overload all operators |
| 09:35:58 | nsf | but nil comparison too? |
| 09:36:36 | * | awsteele quit (Client Quit) |
| 09:36:54 | nsf | have no idea how nil is implemented and whether you can actually override those |
| 09:37:08 | nsf | in modern C++, there is nullptr_t |
| 09:37:27 | nsf | and you can override operator== for nullptr_t as one of operands, something similar in nim? |
| 09:38:29 | * | sepisoad joined #nim |
| 09:38:35 | * | vendethiel quit (Ping timeout: 246 seconds) |
| 09:38:45 | nsf | or perhaps nil is generic and works for any type, but "distinct" simply removes all operator overloads (are they automatically generated for ref object types?) |
| 09:38:50 | nsf | anyways, interesting thing |
| 09:40:44 | * | zepolen quit (Remote host closed the connection) |
| 09:47:40 | * | zepolen joined #nim |
| 09:48:38 | * | cyraxjoe joined #nim |
| 09:49:30 | * | cyraxjoe_ quit (Ping timeout: 260 seconds) |
| 09:51:53 | * | zepolen quit (Ping timeout: 246 seconds) |
| 10:03:53 | * | vendethiel joined #nim |
| 10:11:46 | * | kerze joined #nim |
| 10:21:47 | * | zepolen joined #nim |
| 10:22:18 | * | zepolen quit (Remote host closed the connection) |
| 10:50:03 | * | yglukhov quit (Remote host closed the connection) |
| 11:39:23 | * | gokr joined #nim |
| 11:39:24 | * | gokr quit (Read error: Connection reset by peer) |
| 11:39:38 | * | gokr joined #nim |
| 11:54:56 | * | jaco60 joined #nim |
| 12:30:33 | * | HakanD quit (Quit: Be back later ...) |
| 12:31:21 | * | irrequietus joined #nim |
| 12:33:46 | * | desophos quit (Read error: Connection reset by peer) |
| 12:40:23 | * | HakanD joined #nim |
| 12:42:04 | * | FreeArtMan joined #nim |
| 13:12:49 | * | HakanD quit (Read error: Connection reset by peer) |
| 13:13:25 | * | HakanD joined #nim |
| 13:23:25 | * | HakanD quit (Quit: Be back later ...) |
| 13:33:08 | * | nsf quit (Quit: WeeChat 1.3) |
| 13:39:08 | * | SirCmpwn quit (Ping timeout: 255 seconds) |
| 13:42:21 | * | SirCmpwn joined #nim |
| 13:48:22 | * | joelmo joined #nim |
| 13:55:11 | * | vendethiel quit (Ping timeout: 276 seconds) |
| 14:02:42 | * | vendethiel joined #nim |
| 14:07:28 | * | kerze_ joined #nim |
| 14:12:47 | * | anonkun joined #nim |
| 14:13:03 | * | anonkun left #nim ("Leaving") |
| 14:22:11 | * | Ven joined #nim |
| 14:34:44 | * | bdenham joined #nim |
| 14:35:03 | * | HakanD joined #nim |
| 14:35:20 | * | bdenham quit (Client Quit) |
| 14:46:41 | * | Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 14:52:21 | * | yglukhov joined #nim |
| 14:54:48 | * | perturbation joined #nim |
| 14:59:05 | perturbation | Anyone who's familiar with tables module in stdlib - CR https://github.com/nim-lang/Nim/pull/3703 please? |
| 15:00:04 | perturbation | I think I fixed a bug with CountTableRef and I want to make sure the fix makes sense |
| 15:03:54 | * | Jesin joined #nim |
| 15:04:36 | * | dixit joined #nim |
| 15:05:25 | * | dixit quit (Client Quit) |
| 15:08:14 | perturbation | bbl |
| 15:08:17 | * | perturbation quit () |
| 15:25:57 | * | gokr left #nim (#nim) |
| 15:31:58 | * | Trustable joined #nim |
| 15:40:17 | * | yglukhov quit (Remote host closed the connection) |
| 15:46:45 | * | nsf joined #nim |
| 16:25:49 | * | pregressive joined #nim |
| 17:04:33 | * | Demon_Fox joined #nim |
| 17:06:15 | * | yglukhov joined #nim |
| 17:11:21 | * | pregressive quit (Remote host closed the connection) |
| 17:11:56 | * | pregressive joined #nim |
| 17:16:23 | * | pregressive quit (Ping timeout: 246 seconds) |
| 17:24:48 | * | kerze_ quit (Quit: Leaving) |
| 17:58:44 | * | HakanD quit (Ping timeout: 272 seconds) |
| 17:59:07 | * | desophos joined #nim |
| 17:59:18 | * | HakanD joined #nim |
| 17:59:18 | * | Jesin quit (Quit: Leaving) |
| 18:07:04 | * | pregressive joined #nim |
| 18:13:51 | * | joelmo quit (Quit: Connection closed for inactivity) |
| 18:25:18 | * | Matthias247 joined #nim |
| 18:34:11 | * | umurgdk joined #nim |
| 18:51:52 | * | sepisoad quit (Ping timeout: 256 seconds) |
| 19:13:15 | * | Trustable quit (Remote host closed the connection) |
| 19:23:26 | * | HakanD quit (Quit: Be back later ...) |
| 19:24:07 | * | umurgdk quit (Remote host closed the connection) |
| 19:36:47 | * | kniteli joined #nim |
| 19:37:23 | * | umurgdk joined #nim |
| 19:43:55 | * | dv- quit (Ping timeout: 240 seconds) |
| 19:51:41 | * | darkf quit (Quit: Leaving) |
| 20:01:15 | * | dv- joined #nim |
| 20:14:54 | * | gokr joined #nim |
| 20:18:40 | * | kerze quit (Ping timeout: 276 seconds) |
| 20:28:28 | * | yglukhov quit (Remote host closed the connection) |
| 20:41:14 | * | kas_ quit (Ping timeout: 255 seconds) |
| 20:45:59 | * | kas_ joined #nim |
| 20:54:17 | * | yglukhov joined #nim |
| 20:58:38 | * | yglukhov quit (Ping timeout: 246 seconds) |
| 21:00:56 | * | BitPuffin|osx joined #nim |
| 21:01:18 | ldlework | hello |
| 21:13:19 | Araq_ | hi |
| 21:18:12 | * | yglukhov joined #nim |
| 21:20:11 | ldlework | Araq_: Macros are insane |
| 21:21:03 | Araq_ | in a good way? |
| 21:23:21 | ldlework | Araq_: yeah |
| 21:23:32 | ldlework | Araq_: I wonder if you have some ideas for me |
| 21:23:49 | Araq_ | always. |
| 21:24:02 | ldlework | if yout get a chance to skim this for context, https://gist.github.com/dustinlacewell/19a69d454218a7321f98 |
| 21:25:11 | ldlework | `component` is a modification of the class macro that records the types created. then `registerComponents` creates a new type called ComponentManager. The macro that creates it creates a `typeName`: Table[string, `typeName`] table for each component type created |
| 21:25:33 | ldlework | So, the result is the ComponentManager has a string-table for each Component type that gets created |
| 21:26:10 | ldlework | (well, a uint-table, not string) |
| 21:26:31 | ldlework | This allows me to instantiate Entities and assign components of any Component type to them |
| 21:26:33 | ldlework | This is nice |
| 21:26:47 | ldlework | But the goal is to actually create Entities and assign components to them, by way of a JSON description |
| 21:27:00 | ldlework | IE, an object, then a list of components and their field values. |
| 21:28:16 | ldlework | I'm not sure how to take {"name": "CVisible", "tile": "@"} or {"name": "CPosition", "x": 10, "y": 20} and create the right type, or how to initialize that type, when the json has different fields |
| 21:28:46 | ldlework | IE, I'm not sure how to map the types to their names, or how to generate code that allows me to use a string, to instantiate the correct type (with the correct field values from the JSON object) |
| 21:29:48 | ldlework | Araq_: should I generate a big case statement that switches on the Component name in the JSON, and then does a specialized marshal for the related type? How do I return the instantiated type since return types can't possibly cover all the possible Component types? |
| 21:33:37 | * | dthrvr joined #nim |
| 21:34:36 | Araq_ | er |
| 21:35:38 | Araq_ | dunno, I would make the macro generate specialized types |
| 21:36:11 | Araq_ | and then take care there is no proliferation of types. |
| 21:37:26 | Araq_ | but you might like it better to just create a base class for Component that the proc with string case can return |
| 21:37:59 | * | HakanD joined #nim |
| 21:40:47 | ldlework | Araq_: lets say with the macro I generate a function that takes a string |
| 21:40:58 | ldlework | And it switches on that string to satements like |
| 21:41:23 | ldlework | of CVisible: to[CVisible](json_data) |
| 21:41:33 | ldlework | of CPosition: to[CPosition](json_data) |
| 21:41:47 | ldlework | How can I return the different types? Is it because I have to use inheritance? |
| 21:41:55 | ldlework | And what does the caller do with the result? |
| 21:42:06 | ldlework | How does the c all site know what kind of Component it is getting back? |
| 21:42:32 | ldlework | Does Nim have type assertions? |
| 21:42:42 | Araq_ | well as I said, CVisible and CPosition have to inherit from 'Component' for this to work out |
| 21:42:57 | Araq_ | the 'of' operator is the check you're asking for. |
| 21:43:26 | ldlework | Araq_: so 'casing' the value, I can discriminate by type and then treat the value as that type? |
| 21:43:46 | Araq_ | yes, but use T(x) not cast[T](x) |
| 21:43:58 | Araq_ | aka type conversions, not casts |
| 21:44:07 | ldlework | Araq_: to is the marshal thing |
| 21:44:17 | Araq_ | I know. |
| 21:45:16 | ldlework | Araq_: Nim is an amazing language |
| 21:45:24 | Araq_ | but I wouldn't do it like this at all. |
| 21:45:33 | ldlework | Araq_: I would LOVE to know how you would do this |
| 21:45:47 | ldlework | I can't believe I got as much of this working as I did. |
| 21:45:55 | ldlework | No data-driven-ness yet, but you make it seem like I'm close |
| 21:46:01 | ldlework | But I'm totally open to a better system. |
| 21:46:05 | ldlework | This macro code is huge! |
| 21:46:31 | Araq_ | of CVisible: action(to[CVisible](json_data)) |
| 21:46:43 | Araq_ | likewise for CPosition etc. |
| 21:47:04 | Araq_ | and 'action' is an overloaded set of actions |
| 21:47:37 | Araq_ | this way you don't need inheritance at all |
| 21:47:52 | Araq_ | but it's just the sketch of an idea, no promise it can work out. |
| 21:48:06 | ldlework | hmm |
| 21:48:10 | ldlework | Maybe I can go even shorter |
| 21:48:13 | ldlework | and just cut to the chase |
| 21:48:15 | ldlework | something like |
| 21:48:39 | ldlework | of CVisible: cm.CVisible[entity_id] = to[CVisible](json_data) |
| 21:48:49 | ldlework | Now I'm loading components right into the component tables. |
| 21:49:09 | ldlework | I suppose your idea is good if I need to do any sort of post-processing on the unmarshaled types. |
| 21:49:20 | ldlework | But evne then I could just generate that code right in the of-blocks... |
| 21:49:22 | ldlework | Hmm |
| 21:49:39 | ldlework | Araq_: you can't use types as values right? |
| 21:49:42 | * | nsf quit (Quit: WeeChat 1.3) |
| 21:49:56 | ldlework | Because it would be super nice to just be able to use types as table keys/values :D |
| 21:50:23 | ldlework | I guess that makes no real sense |
| 21:52:10 | Araq_ | actually you can do that |
| 21:52:20 | Araq_ | but it's never been shown to anybody :P |
| 21:52:39 | ldlework | whaaaaaaat |
| 21:52:51 | ldlework | lol |
| 21:53:02 | Araq_ | and I need to lookup all sort of things |
| 21:53:20 | Araq_ | but RTTI exists and you can hrm |
| 21:53:53 | ldlework | Araq_: you know what these entity systems are/for? |
| 21:54:02 | ldlework | like you get them conceptually |
| 21:54:24 | Araq_ | no, because nobody does. ;-) They are in constant research. |
| 21:55:14 | Araq_ | I know a bit about entity systems but I lack game programming experience to judge whether they are really useful or most of the time just overkill |
| 21:55:17 | niv | hey Araq! i'm really enjoying writing nim code. </interlude> |
| 21:55:18 | ldlework | Araq_: I mean the baic premise is all |
| 21:56:13 | ldlework | Araq_: at minimum, the goal is to associate a number of object types with a unique identifier. So you might have three types, A, B and C. Then you might that two "entities" which is just a number, say 1 and 2. |
| 21:56:28 | ldlework | The idea is to then, be able to associate any number of component instances with either entity. |
| 21:56:37 | ldlework | So say, A and B with 1 and B and C with 2. |
| 21:57:01 | ldlework | I have that so far, just generate tables for each type and store component instances by entity ID |
| 21:57:02 | ldlework | I have that. |
| 21:57:09 | ldlework | Now the tricky part is driving it with data. |
| 21:57:43 | ldlework | So reading in a file that says "There exists an entity 1, that has component A with fields tile="@", and component B with fields x=10, y=5" |
| 21:57:46 | Araq_ | ldlework: yeah I know, but plain old delegation/aggregation solves that too |
| 21:58:09 | ldlework | And then doing the correct instantiations and record keeping in those tables. |
| 21:58:36 | ldlework | Araq_: I am totally open to actual in-language implementation techniques - I only care that I can load the eventual tables by way of JSON descriptions. |
| 21:59:24 | Araq_ | niv: thanks, always nice to hear :-) |
| 22:00:01 | Araq_ | ldlework: I wrote an RTS "engine" once, scriptable by Lua. |
| 22:00:02 | ldlework | Araq_: the diffuclty is the fact that the components are different types |
| 22:00:17 | ldlework | Araq_: cool :D |
| 22:00:25 | ldlework | Araq_: Nim has Lua support right? |
| 22:00:43 | Araq_ | I had a 2 map with every square having a pointer to a 'Unit' |
| 22:00:53 | Araq_ | *a 2d map |
| 22:00:57 | ldlework | right |
| 22:01:14 | ldlework | Araq_: the goal is to be able to create new Unit types without recompiling the game. |
| 22:01:27 | Araq_ | and just that, well it was a tad more complicated |
| 22:01:41 | Araq_ | and then in Lua the Unit definitions |
| 22:01:54 | Araq_ | but in the engine itself there was only 1 type to deal with |
| 22:02:23 | Araq_ | with lots of properties like 'canFly' |
| 22:02:43 | Araq_ | well ok, to save space there was Unit and UnitClass |
| 22:02:49 | ldlework | Right the goal is to get away from properties like "canFly" |
| 22:03:02 | Araq_ | each unit having a pointer to its class |
| 22:03:09 | ldlework | Having large parametric classes |
| 22:04:16 | Araq_ | it wasn't so bad and people could script the game and create new unit types |
| 22:04:17 | ldlework | With an ECS |
| 22:04:25 | ldlework | I'm not saying it is bad |
| 22:04:38 | ldlework | People been making games with monolithic entity classes for a long time |
| 22:04:56 | Araq_ | now with an ECS, you can either hide the fact that you have that mono class |
| 22:05:19 | Araq_ | by generating it from a macro, so you can distribute it, kind of. |
| 22:05:30 | Araq_ | or you actually distribute its storage |
| 22:05:46 | ldlework | heh |
| 22:05:49 | ldlework | so you're suggesting |
| 22:05:50 | Araq_ | by having more than 1 'array' holding these things and dealing with IDs |
| 22:05:52 | ldlework | modify the class macro |
| 22:05:58 | ldlework | to actually pool definition blocks |
| 22:06:12 | ldlework | and then to actually conglomorate a single monolith type |
| 22:06:12 | * | kas_ quit (Ping timeout: 250 seconds) |
| 22:06:18 | ldlework | and then boom, the question I asked is done? |
| 22:06:20 | ldlework | lmfao |
| 22:06:37 | Araq_ | so, that seems to be your question. Wether you distribute it only at compile-time or also at run-time. |
| 22:06:40 | ldlework | that is fuckin hilarious |
| 22:07:00 | * | ldlework ponders that. |
| 22:07:14 | ldlework | Well |
| 22:07:38 | Araq_ | and of couse all sort of efficiency considerations play a role here too. but ... since you're not developing an AAA game, shouldn't. |
| 22:07:57 | ldlework | Well you would think that the monolith would be faster but heavier. |
| 22:08:08 | ldlework | Since there's no runtime look up many hash tables. |
| 22:08:11 | Araq_ | so ... we shall assume efficiency is irrelevant and you only care about how to model things |
| 22:08:19 | ldlework | Which is basically true. |
| 22:09:07 | Araq_ | now, if you distribute it at runtime, destruction is a problem |
| 22:09:12 | ldlework | Araq_: this is a fascinating take. I've been studying ECS for years and I have *never* come across this insight before. |
| 22:09:22 | ldlework | anywhere |
| 22:09:32 | ldlework | probably because the languages everyone is using can't do this |
| 22:09:52 | ldlework | Araq_: okay let me stand up a critique |
| 22:10:30 | ldlework | part of the advantage with true ECS is that the gameplay systems have an inherently natural way to gather the entities in the game that are relevant to that game system |
| 22:10:43 | ldlework | for example a RendererSystem might care about entities with a Position and a Sprite |
| 22:10:54 | ldlework | And a PhysicsSystem might care about entities with a Position and a Velocity |
| 22:11:18 | ldlework | If you go the monolithic type route, you need an easy way to tell "what collections of fields are actually relevant for this entity" |
| 22:11:24 | ldlework | Is that just a shit ton of bools on the object? |
| 22:11:34 | Araq_ | that's just a bitset |
| 22:11:41 | ldlework | But you might have tons of components |
| 22:11:43 | Araq_ | likely 1 word or less for Nim |
| 22:12:28 | ldlework | Araq_: can you hold more values in the bitset than there are bits? |
| 22:12:48 | Araq_ | the compiler computes the required size for you at compile-time |
| 22:13:32 | ldlework | where are bitsets described? not in the manual |
| 22:13:42 | Araq_ | it's just called 'set' in Nim. |
| 22:13:46 | ldlework | ah |
| 22:14:51 | Araq_ | also you don't need to go the mono type route |
| 22:15:15 | Araq_ | but I would do it, because I'm a crank. |
| 22:15:36 | ldlework | well it seems to have some advantages... |
| 22:16:08 | Araq_ | now, if you distribute the type |
| 22:16:13 | ldlework | After all, all of the advantages to ECS seem to be compile-time structural advantages... |
| 22:16:27 | Araq_ | you need to distinguish between hard and soft references. |
| 22:16:39 | Araq_ | actually ... you need this distinction anyway I think. |
| 22:16:44 | ldlework | What? |
| 22:17:33 | Araq_ | for example, the selected units shouldn't be kept alive just because they are selected |
| 22:17:45 | Araq_ | so the UI holds weak refs to the units |
| 22:17:52 | Araq_ | or some comparable mechanism |
| 22:19:04 | ldlework | Well kept alive is a wierd way to put it |
| 22:19:23 | Araq_ | perhaps. |
| 22:19:41 | ldlework | Whether the entity has no references out there in the code and has been cleaned up by the GC is different than whether the game logically considers a unit to be deceased and unselectable/unrenderable/etc |
| 22:20:21 | Araq_ | well that's my point. the GC won't tell you when the unit is dead. |
| 22:20:38 | ldlework | right but generally those two events are not related at all |
| 22:21:06 | ldlework | generally a referenced entity will be killed, logically in terms of field values on the object, and then later discarded from data structures. |
| 22:21:16 | ldlework | IE, you don't kill things in the game by unreferencing them everywhere. |
| 22:21:30 | Araq_ | ok ok, but let's move on |
| 22:21:34 | ldlework | hehe ok |
| 22:22:57 | Araq_ | when you have a mono type you can store all the instances in one seq and when you remove an instance all subsystems automatically stop handling it |
| 22:23:03 | ldlework | I'm having a hard time coming up with justifications for actually distributed types |
| 22:23:15 | ldlework | exactly! |
| 22:23:25 | ldlework | each system just gets all the entities and does a bitset filter |
| 22:23:32 | ldlework | it seems far more straight forward... |
| 22:23:46 | ldlework | wait |
| 22:23:51 | Araq_ | well it's justified for a commercial engine where you just buy the physics engine part from another vendor or something |
| 22:23:54 | ldlework | can.. I use types as the bitset values? |
| 22:24:14 | ldlework | like what would the query interface be |
| 22:24:16 | Araq_ | no, but you do that mapping via a macro |
| 22:24:18 | ldlework | I have an entity instance |
| 22:24:25 | ldlework | oh hmm |
| 22:24:42 | ldlework | so subsystems will use a macro to filter the entity list based on type nnkIdent's I pass to it |
| 22:24:50 | ldlework | or something? |
| 22:24:59 | Araq_ | you still have a macro fighting the boilerplate |
| 22:25:10 | Araq_ | via some name convention |
| 22:25:12 | ldlework | filterThis(entities, [CVisible, CPosition]) ? |
| 22:25:14 | ldlework | something like that? |
| 22:25:40 | Araq_ | oh yeah, I think so. |
| 22:25:48 | ldlework | that's such a nice interface |
| 22:25:59 | ldlework | can you call macros on types? |
| 22:26:07 | Araq_ | yeah |
| 22:26:10 | ldlework | entities.filterThis([CVisible, Cposition]) |
| 22:26:12 | ldlework | wow |
| 22:26:33 | * | ldlework hugs Araq_ |
| 22:26:37 | Araq_ | but I don't think that's actually necessary |
| 22:26:43 | ldlework | which part |
| 22:26:59 | Araq_ | you only need to transform CVisible to CVisibleFlag |
| 22:27:10 | Araq_ | i.e. append 'Flag' to the identifier. |
| 22:27:18 | Araq_ | in the macro. |
| 22:27:34 | ldlework | ah, so I guess that answers the question of whether I can use the types themselves at bitset values |
| 22:27:48 | ldlework | wait what is the type of the bitset? |
| 22:27:58 | Araq_ | the macro generates an enum |
| 22:28:09 | ldlework | aha |
| 22:28:23 | ldlework | this feels so incredibly evil!!! |
| 22:29:10 | Araq_ | well don't overdesign it, how many different components do you actually have? I always see people claim they have hundreds and yet they always list position and velocity |
| 22:29:12 | ldlework | I should clean up and abstract this macro generation code a bit more |
| 22:29:30 | Araq_ | and nothing else. |
| 22:30:08 | ldlework | Araq_: If I don't make a game, it is a long-term goal of mine to implement an _nice to use_ ECS in a type-safe language for years |
| 22:30:41 | Araq_ | ok but then you're designing a system for Nim, not for you. |
| 22:30:50 | ldlework | huh? |
| 22:31:01 | Araq_ | I mean |
| 22:31:36 | Araq_ | if you create a general purpose ERS, you definitely need to support non-mono type creations |
| 22:31:44 | ldlework | Why? |
| 22:32:33 | ldlework | I think you're onto something when you observed, that in the abstract, there is *always* a mono type |
| 22:32:38 | ldlework | I think that is deeply insightful |
| 22:32:51 | Araq_ | because people like to buy external physics engines |
| 22:32:52 | ldlework | ECS offers no run-time advantages... |
| 22:33:00 | ldlework | Araq_: that has nothing to do with it though |
| 22:33:06 | Araq_ | no? |
| 22:33:12 | Araq_ | why not? |
| 22:33:29 | Araq_ | the physics engine comes with its own notions of positions and velocities |
| 22:33:33 | ldlework | I don't think so. You can specify the data in a component, and then a subsystem uses an external physics engine and your component data. |
| 22:33:52 | Araq_ | and if you went for a distributed entity system from the start, it's natural |
| 22:33:52 | ldlework | Sure, but that shouldn't inherently prevent you from using that engine to modify the states of your own objects. |
| 22:34:12 | ldlework | The physics engine isn't going to be built to integrate with my system. |
| 22:34:24 | ldlework | So either my system will have explicit code for mapping entities to physical bodies. |
| 22:34:29 | ldlework | Or the application author will. |
| 22:34:44 | Araq_ | yeah, you might be right about that. |
| 22:34:52 | ldlework | Having the physics simulated independently of the world state is typical. |
| 22:35:31 | Araq_ | alright, well, happy hacking then. :-) |
| 22:36:40 | ldlework | Araq_: here's the repo I'm working, https://github.com/dustinlacewell/dadren |
| 22:40:23 | * | vendethiel quit (Ping timeout: 276 seconds) |
| 22:40:29 | Araq_ | cool, but why not realtime? turn based games tend to be ... |
| 22:40:43 | Araq_ | hmm apparently English has no word for it? |
| 22:42:22 | Araq_ | ah, 'dull'. |
| 22:44:04 | * | vikaton joined #nim |
| 22:53:04 | * | HakanD quit (Quit: Be back later ...) |
| 22:57:30 | ldlework | Araq_: They're also much harder to implement and less susceptable to data-driven ness |
| 22:57:43 | ldlework | Araq_: this whole engine is going to be entirely data-driven |
| 22:57:55 | ldlework | Araq_: have you never played a good roguelike? |
| 22:58:11 | Araq_ | I don't think I did. |
| 22:58:27 | ldlework | Araq_: I can recommend one or two if you'd like |
| 22:58:51 | ldlework | Accessible ones, that don't take a huge learning curve or have horrible interfaces |
| 22:59:11 | * | zepolen joined #nim |
| 22:59:15 | ldlework | Araq_: https://crawl.develz.org/ |
| 22:59:52 | ldlework | neat you can watch people play on the web now |
| 23:03:36 | * | vendethiel joined #nim |
| 23:05:35 | * | FreeArtMan quit (Ping timeout: 264 seconds) |
| 23:11:23 | ldlework | Araq_: is there anywhere to stick global compile-time data? |
| 23:11:49 | * | gokr quit (Ping timeout: 245 seconds) |
| 23:12:05 | Araq_ | a .compileTime global var perhaps? |
| 23:12:21 | ldlework | is that available outside of the defining module? |
| 23:12:33 | ldlework | eh I guess I don't need a global |
| 23:24:25 | * | vendethiel quit (Ping timeout: 260 seconds) |
| 23:24:44 | dom96 | interesting issue: https://twitter.com/tankfeeder/status/686263778783137792 |
| 23:28:41 | * | FreeArtMan joined #nim |
| 23:28:42 | dom96 | Anybody with Android can verify whether its browser crashes on http://nim-lang.org/docs/lib.html? |
| 23:29:47 | dom96 | Good night |
| 23:31:09 | def- | dom96: takes a second to load, but no crash |
| 23:40:12 | ldlework | Araq_: I was thinking "hmm, the runtime efficiency could be had with distributed types by caching lookups" |
| 23:40:30 | ldlework | Araq_: but then I thought, when you're in the gameplay code and you go "give me all the entities with a CSprite and CPosition components" |
| 23:40:50 | ldlework | you get back values that have the fields of both CSprite and CPosition as first-level attributes |
| 23:41:04 | ldlework | compared to having to indirect to distinct child structures or anything else |
| 23:41:26 | ldlework | (I don't know if Nim has some crazy magic that can return literally unified values like that, but I'm guessing not) |
| 23:43:08 | ldlework | also it sucks being so west of the nim community heh |
| 23:43:33 | Araq_ | yeah we need more Americans in #nim |
| 23:44:23 | ldlework | Araq_: I think the field access egronomics is justification enough for the unified ecs model |
| 23:44:31 | ldlework | do you agree? |
| 23:45:25 | ldlework | Araq_: hmm with the unified type, I can't unmarshal component descriptions anymore hmm |
| 23:45:41 | ldlework | I have to have some code that takes a value from json and sticks it into the right field in the unified type |
| 23:46:41 | ldlework | I need a PHP like language for nim-code so I can just abuse parseStmt more easy |
| 23:46:49 | * | FreeArtMan quit (Ping timeout: 245 seconds) |
| 23:46:53 | ldlework | lol |
| 23:53:05 | ldlework | Araq_: do you think it would be possible to overload `.` for the unified Entity type such that, at run time it checks the attribute name against the bitset and a list of fields that are available for the active components in the bitset? |
| 23:53:21 | ldlework | and like raise an exception if some code tries to access to fields that are not enabled by the bitset? |
| 23:54:24 | * | yglukhov quit (Remote host closed the connection) |
| 23:55:05 | ldlework | ugh this is starting to hurt my brain |