pouët.net

GNU Rocket on non-Windows platforms

category: code [glöplog]
Also there is this version of the editor that is also xplatform:

https://github.com/emoon/rocket/tree/master/ogl_editor

BB Image
added on the 2014-07-28 22:10:20 by emoon emoon
Yep, emoons editor is really neat :)
added on the 2014-07-28 22:28:13 by kusma kusma
Thanks :) Lets try the link again.

https://github.com/emoon/rocket/tree/master/ogl_editor

One thing I support in my editor is groups and track folding which I really missed from the old windows editor (also I use pretty much Mac only at home and using Wine/Parallels becomes old after a while) so I coded my own.

I have never really officially announced it but it works on Mac, Windows and Linux (on Linux SDL is required) and have been used in a bunch of productions.
added on the 2014-07-28 22:37:47 by emoon emoon
Quote:
Maali: Sorry, but my fix was to remove *all* personal mentions.


That's so Janteloven of you :)
added on the 2014-07-29 10:06:46 by skrebbel skrebbel
Quote:
Quote:
Maali: Sorry, but my fix was to remove *all* personal mentions.


That's so Janteloven of you :)


Nah, it's lazyness. There's more contributors these days than when I originally wrote the copyright-statement. I don't want to spend time on maintaining these things, so it was easier to just remove them all. The commit history already tracks who wrote what, without any effort ;)
added on the 2014-07-29 10:25:59 by kusma kusma
Ah right. That actually makes sense.
added on the 2014-07-29 20:34:32 by skrebbel skrebbel
Speaking of Rocket ports: I was dissatisfied with how many weird VS project I needed to convert to compile DotRocket, and I didn't like all the compiler/linker warnings, and I didn't like that there wasn't an x64 compatible version, so I decided to port the client/player lib to C# without any dependencies.

So I hereby present: https://github.com/kebby/RocketNet

It should be easier to link, and as a plus it should also work on all Mono platforms if you're so inclined. Tested with the small demo system I'm currently conjuring up, and example code coming up when there's demand.

Biggest disadvantage: As it doesn't link against the original client lib, somebody will have to maintain it in case the feature set or protocol changes. But as this hadn't happened in how many years now that's a rather miniscule point :)
added on the 2014-12-03 03:22:27 by kb_ kb_
Who's awesome? kebby is awesome! :) Great stuff!
added on the 2014-12-03 21:24:39 by xTr1m xTr1m
Are the tabs automatically generated from the track name?
added on the 2015-05-27 23:54:28 by Gargaj Gargaj
gargaj: Yeah. I do want to have manual grouping also, but as a first step this should be better than the mess it quicky became before. "default" contains all tracks, though.
added on the 2015-05-28 00:09:41 by kusma kusma
Manual grouping as in by the user or by the coder? (Assuming they're different.) I'm doing a similar thing in my tool but I'm going the DAW-way where you can group anything, even other groups, because I often misjudge which tracks I need to see next to each other when editing :D
added on the 2015-05-28 00:30:15 by Gargaj Gargaj
Gargaj: The user. My longer term plan is create "filter tabs" that contain tracks matching a prefix or a filter, and also possibly editable sets. But we'll see, some times we find out we don't need the more involved stuff, and I have enough other things to work on ;)
added on the 2015-05-28 00:40:19 by kusma kusma
I'll just leave this here...
BB Image

github - pouet
added on the 2015-05-28 11:41:01 by TLM TLM
kusma: which branch is active? I have a minor bug report in master, but you may have already fixed it in one of the other branches ;)

Thread resurrection ftw!
added on the 2016-02-02 22:19:43 by cxw cxw
@cxw: Still master. I've been committing to it over the last few days ;)
added on the 2016-02-03 00:52:27 by kusma kusma
Feel free to file tickets in the github repo, if that suits you...
added on the 2016-02-03 01:16:32 by kusma kusma
Gonna try that editor @TLM, looks great.
added on the 2016-02-04 21:17:50 by superplek superplek
Just a little hint for intro coders using usync: Don't you think that you can simply remove the call to floor() in usync_update and replace it with a cast to int. /QIfist is your enemy in this case. You really need to round that float down. Spent hours of debugging this yesterday ^^
added on the 2016-02-05 08:41:47 by xTr1m xTr1m
xTr1m: I'm a bit surprised why that didn't work... float -> int cast should truncate, which should in turn be the same as floor() for non-negative values... And the position should never be negative...
added on the 2016-02-10 00:36:58 by kusma kusma
Doesn't that depend on the rounding mode?
added on the 2016-02-10 00:52:56 by Gargaj Gargaj
When using crinkler and not linking to the msvcrt, you depend on compiler flags like /QIfist, which implement _ftol as a simple fist asm instruction. The documentation of /QIfist specifically mentions that it might change rounding mode, which it does in my case.
I had to implement my own floor method, it's pretty small when using SSE.
added on the 2016-02-10 09:20:28 by xTr1m xTr1m
Not according to the C++ spec... [conv.fpint] Section 4.9.1 says "A prvalue of a floating point type can be converted to a prvalue of an integer type. The conversion truncates; that is, the fractional part is discarded. The behavior is undefined if the truncated value cannot be represented in the destination type."

But it seems /QIfist breaks this behavior... So yeah, perhaps it's worth keeping that otherwise pointless floor() call...
added on the 2016-02-10 09:20:42 by kusma kusma
(my previous post were meant for Gargaj, if that isn't obvious)
added on the 2016-02-10 09:25:15 by kusma kusma
kusma: Precisely, the c++ spec explicitly mentions a truncation of the fractional type. But in order to map that functionality to the x86 architecture, the MS VC++ compiler generates a call to _ftol (or its later, more performant, implementations), which ensures that the CPU flags for the floating point rounding mode is set to round down, prior to converting the float to int. It's the call to _ftol which disturbs intro coding, since its implementation resides in the MSVCRT. I don't want to link the MSVCRT, which then causes an unreferenced external symbol error. That's why I use /QIfist.

And by the way, the implementation of floor() is also in the MSVCRT... :)
added on the 2016-02-10 09:35:55 by xTr1m xTr1m

login