What are you working on? v67 - March 2017 - Developers

I'm getting close to releasing the next version of my ECS and I was wondering what to do about the versioning scheme. There is a small breaking change and it adds a lot of features, but it doesn't really feel like version 2.0. Just call it 1.1? That seems a bit like a disservice though, because there's quite a lot of new stuff, but at the same time I didn't release any version 1.x so I don't know.

[QUOTE=WTF Nuke;52004172]I'm getting close to releasing the next version of my ECS and I was wondering what to do about the versioning scheme. There is a small breaking change and it adds a lot of features, but it doesn't really feel like version 2.0. Just call it 1.1? That seems a bit like a disservice though, because there's quite a lot of new stuff, but at the same time I didn't release any version 1.x so I don't know.[/QUOTE] Is it possible to avoid the breaking change or make it backwards compatible?

Yeah but it's really tiny and would be very easy to upgrade, plus I'm not sure if anyone actually uses the library.

[QUOTE=WTF Nuke;52004819]Yeah but it's really tiny and would be very easy to upgrade, plus I'm not sure if anyone actually uses the library.[/QUOTE] You'll be certain that nobody uses it if you break semantic versioning. You need to get it out of your head that "major version = milestone".

So if it's not backwards compatible it should be 2.0? I realize now that there is a big change that cannot be done in a backwards compatible way.

[QUOTE=WTF Nuke;52004172]I'm getting close to releasing the next version of my ECS and I was wondering what to do about the versioning scheme. There is a small breaking change and it adds a lot of features, but it doesn't really feel like version 2.0. Just call it 1.1? That seems a bit like a disservice though, because there's quite a lot of new stuff, but at the same time I didn't release any version 1.x so I don't know.[/QUOTE] This is what i usually try to go with [url]http://semver.org/[/url] [editline]24th March 2017[/editline] Oh shit, new page with more posts.

[QUOTE=WTF Nuke;52004866]So if it's not backwards compatible it should be 2.0? I realize now that there is a big change that cannot be done in a backwards compatible way.[/QUOTE] Even if there's the tiniest breaking change, bump the major version. Most developers and a lot of build tools assume this is how it works. Also rename your dll if you build to one in this case (if there's not a different huge issue). If you add any functionality at all, bump the minor version. Again, not doing this can cause pretty severe weirdness with build tools in certain environments.

[QUOTE=Tamschi;52005150]Even if there's the tiniest breaking change, bump the major version. Most developers and a lot of build tools assume this is how it works. Also rename your dll if you build to one in this case (if there's not a different huge issue). If you add any functionality at all, bump the minor version. Again, not doing this can cause pretty severe weirdness with build tools in certain environments.[/QUOTE] It's it also common practice to mark functions and classes as deprecated before you completely remove/change them in a new major version? I'm only taking this from how Unity does it.

So I got back to work on PortalKit Pro to add some features that users were requesting. Today, I managed to add/fix -Single pass stereo functionality -Microscopic wiggling if you stare at the edge of a portal and don't move at all (this seemed silly at first but once I noticed it I wanted to rip my eyes out) -Multilanguage documentation (Only JP for now) -Settable, instead of auto-detected, player bounds -VRTK support, with VRTK included in the asset itself now (Yay MIT license!) This is all nonvisual but for now have a teaser for a campaign I'm gonna run on it soon while trying to sell it to reddit and the Rick and Morty folks [img]http://i.imgur.com/H0LTxUP.gif[/img] Gonna probably get back to work on clouds and releasing the dithering shader for free when I get time again now that midterms are over.

[QUOTE=AtomiCal;52005514]It's it also common practice to mark functions and classes as deprecated before you completely remove/change them in a new major version? I'm only taking this from how Unity does it.[/QUOTE] I mostly see that with very large (businessy) libraries and only if that function and/or class actually is worse than using a newly added feature instead (like OpenGL's slow immediate mode, for example). With smaller libraries, the new version tends to be a rewrite or something similar, with some of the old functionality completely removed. The old version usually continues to be supported with bug fixes in that case though, and there should be some upgrade guide (especially highlighting changes that behave differently without causing a compilation failure or other error).

It doesn't look like much but my group and I got A* working for our simulation project. It's all of our first times coding A* but the biggest hurdle was realizing we had a semicolon after an if statement. [img]http://i.imgur.com/5Zwno5x.gif[/img]

[QUOTE=Baboo00;52007346]It doesn't look like much but my group and I got A* working for our simulation project. It's all of our first times coding A* but the biggest hurdle was realizing we had a semicolon after an if statement. [img]http://i.imgur.com/5Zwno5x.gif[/img][/QUOTE] Its indecisiveness is kinda cute in a way.

some of you might remember me as the guy who made a beautiful horse with unity primitives well i'm back with more horse [t]http://i.imgur.com/XhgOmqG.gif[/t] [t]http://i.imgur.com/gTzFHL2.gif[/t] [t]http://i.imgur.com/O8I93zP.gif[/t] [t]http://i.imgur.com/Cw2pq9G.gif[/t]

[QUOTE=cam64DD;52008008]some of you might remember me as the guy who made a beautiful horse with unity primitives well i'm back with more horse [t]http://i.imgur.com/XhgOmqG.gif[/t] [t]http://i.imgur.com/gTzFHL2.gif[/t] [t]http://i.imgur.com/O8I93zP.gif[/t] [t]http://i.imgur.com/Cw2pq9G.gif[/t][/QUOTE] sorry for the meme but this belongs in a museum

Experimented this week with unity/webgl/websockets [url]http://shooty.facepunch.com/[/url] It's using a really minimal dedicated server instead of a Unity server. Which is probably stupid tbh because that means the server isn't simulating physics or anything, it's just echo'ing packets.

[QUOTE=garry;52008245]Experimented this week with unity/webgl/websockets [url]http://shooty.facepunch.com/[/url] It's using a really minimal dedicated server instead of a Unity server. Which is probably stupid tbh because that means the server isn't simulating physics or anything, it's just echo'ing packets.[/QUOTE] [vid]https://my.mixtape.moe/tmgzmc.webm[/vid] [editline]24th March 2017[/editline] [url]http://pastebin.com/m34nGDmS[/url]

Works fine for me

[QUOTE=cam64DD;51994127]I think my game's combat system is finally ready! You, the player, will be able to control up to 4 party members. Each party member has a key (default keys are H,J,K and L). When your character is attacking, you gotta press their key whenever their weapon blinks in order to keep the combo going. You'll also have to pay attention to the arrows on top of your foe's head, because you have to press the movement keys accordingly. Failing to do so will result in weaker blows. [video=youtube;NAt6Njiwx_I]https://www.youtube.com/watch?v=NAt6Njiwx_I[/video] Oh and by the way, I finally found myself a composer! Turns out one of the guys who composed music for Homestuck liked my game. [URL="https://twitter.com/spellbang"]@spellbang[/URL] is now working on the soundtrack! The song that plays in the video is one of the tracks he made for the game: [URL="https://soundcloud.com/spellmynamewithabang/gore-this-most"]gore this most[/URL]! I'm pretty happy with the path this game is taking. A demo will come out by july![/QUOTE] looking really good, i love the new screenshots you posted. care to detail how the combat system works? are the qte prompts timed? can you block attacks 100% of the time? also just a small nit pick but characters should walk to their target a lot quicker. if we are looking at a long rpg game having to wait for an enemy to walk up to attack you ends up chewing up a lot of time.

[QUOTE=garry;52008245]Experimented this week with unity/webgl/websockets [url]http://shooty.facepunch.com/[/url] It's using a really minimal dedicated server instead of a Unity server. Which is probably stupid tbh because that means the server isn't simulating physics or anything, it's just echo'ing packets.[/QUOTE] [IMG]https://i.gyazo.com/f042421d486b5bfccc4d7a66d70d7865.png[/IMG] Probably not the goal, but I escaped

[QUOTE=garry;52008245]Experimented this week with unity/webgl/websockets [url]http://shooty.facepunch.com/[/url] It's using a really minimal dedicated server instead of a Unity server. Which is probably stupid tbh because that means the server isn't simulating physics or anything, it's just echo'ing packets.[/QUOTE] If there's supposed to be any jumping then that's kinda broken for me. If there's not, getting up stairs seems to be somewhat difficult. Like the level layout tho, felt very familiar very quickly. :P

[QUOTE=garry;52008245]Experimented this week with unity/webgl/websockets [url]http://shooty.facepunch.com/[/url] It's using a really minimal dedicated server instead of a Unity server. Which is probably stupid tbh because that means the server isn't simulating physics or anything, it's just echo'ing packets.[/QUOTE] I can get into the game, but once there I can't do anything. Lame.

[QUOTE=Baboo00;52007346]It doesn't look like much but my group and I got A* working for our simulation project. It's all of our first times coding A* but the biggest hurdle was realizing we had a semicolon after an if statement. [img]http://i.imgur.com/5Zwno5x.gif[/img][/QUOTE] That doesn't look like A*

[QUOTE=phygon;52010214]That doesn't look like A*[/QUOTE] Maybe it's placing nodes down as it goes

2 weeks until something I'm working on is shipped off to NASA for final pre-launch tests and launch packing. [sp]Holy fuck we are not ready fuck fuck fuck[/sp] second spoiler: [sp]My software is tied to the whole 2yr contract the hardware belongs to, but the hardware work I've done on it is intern bitchwork like twisting wires. I can't even solder, it has to be soldered to NASA standards and I'm terrible at that lol[/sp] [editline]edit[/editline] The only upside to being an intern and restricted to 30hrs/wk like I am is that I'm not in on the weekends, like everyone on that team is rn. And if I want to avoid getting made to do things like twisting wires, I just stay at home and work on my software stuff from home :v:

[QUOTE=paindoc;52011026]2 weeks until something I'm working on is shipped off to NASA for final pre-launch tests and launch packing. [sp]Holy fuck we are not ready fuck fuck fuck[/sp] second spoiler: [sp]My software is tied to the whole 2yr contract the hardware belongs to, but the hardware work I've done on it is intern bitchwork like twisting wires. I can't even solder, it has to be soldered to NASA standards and I'm terrible at that lol[/sp] [editline]edit[/editline] The only upside to being an intern and restricted to 30hrs/wk like I am is that I'm not in on the weekends, like everyone on that team is rn. And if I want to avoid getting made to do things like twisting wires, I just stay at home and work on my software stuff from home :v:[/QUOTE] Now imagine doing the same thing for a manned launch.

[QUOTE=LennyPenny;52000272]Wait did you really sit down and manually make a lookup table of words and their responding clips[/QUOTE] Nope, automated intake system based on Speech recognition from IBM Watson. [QUOTE=phygon;52002955]Please release this[/QUOTE] I fully intend to release it as a web-app once it's been cleaned up and had some improvements. [QUOTE=elitehakor;52003042]now do it with phonetic sounds[/QUOTE] It'd be amazing to do, but we'll see. For now the plan is to add some form of sentiment and contextual analysis, as well as some quality testing.

[QUOTE=Pat.Lithium;52008902]looking really good, i love the new screenshots you posted. care to detail how the combat system works? are the qte prompts timed? can you block attacks 100% of the time? also just a small nit pick but characters should walk to their target a lot quicker. if we are looking at a long rpg game having to wait for an enemy to walk up to attack you ends up chewing up a lot of time.[/QUOTE] I've changed a lot about the combat system! Now there's a timer for your turn: you can freely use any party memeber's abilities provided that the timer hasn't hit zero. Certain attacks and abilities restore time to the timer. Some people have tested it and they all liked it! Yes, QTE prompts are timed. You can block attacks 100% of the time, if you manage to get the timing right. And I've changed all animation speeds! Characters now don't walk to their targets anymore, they just hop straight to their targets. Feels much faster now and I love it! I'll be sharing a video about the new system soon.

It was probably more luck than good programming, but I'm pretty proud of this goal. [vid]https://fat.gfycat.com/WeakHeartyErin.webm[/vid]

[QUOTE=JWki;52011232]Now imagine doing the same thing for a manned launch.[/QUOTE] Yay cheaper unmanned launches doing all the cargo stuff! Although, our module is going to be used by astronauts. As such, we have an 800 page manual of things we have to comply to. Did you know that all switches have to be switchable by someone with finger strength in second percentile? Did you know an intern can be made to test switches for things like this? I didn't. Until I was the intern :I

Well, I'm certainly in somewhat of an interesting position now. So basic game loop with 0 frames of lag (no buffering between frames whatsoever, i do support buffering for increased perf): 1. Render shadows, render transparency context (first, to overlap with other processing time and to keep the gpu busy) 2. Game logic, including mouse/keyboard input handling 3. Flush object positions to gpu on a second opencl queue 4. Do rendering for the main context (primary opencl queue) 5. Blit to screen etc This means that shadows and transparent items lag 1 frame behind, but this is fine because the performance gain means that 0 frames of lag is more usable (and also who cares) Downside: There is seemingly no high performance way to ensure that the objects flushed in step 3 actually arrive in time for the rendering on step 4. Any solution I try takes the frametime from 4ms/frame -> 6ms/frame ish (probably because it has to synchronise two different queues, but using just one queue is in itself quite significantly lower performance, particularly on nvidia). There's not enough available gpu work (shadows and transparency) to start one later and overlap the transfer, with the first, then wait, both of these are *nearly* free. Yet, left to its own devices, the driver seems to schedule things such that they do always arrive in time This seems to be dependent on the number of calls to clenqueuewritebuffer rather than how much data is being written - because the new hand model generates a lot of extra calls, half the objects in the scene started updating 0-1 frames behind (creating a bunch of stuttering), whereas objects created 'earlier' (and therefore flushed to the gpu earlier) updated consistently (temporarily fixed by halving the number of writes I make) So now I'm a position where by default the driver does exactly what I would like it to do in a high performance way, but there's absolutely no guarantee that it will keep working into the future, and I can't find an opencl construct that will force the driver to keep doing what its doing now. #rip. Its also quite possible that *other* objects in the scene are arriving one frame behind, but because the base fighter is always the first object updated, this means that its data will arrive first, so it may be possible that a high performance solution may be to *only* synchronise objects tied to the camera (to prevent jitter)