Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - ferris

Pages: [1] 2 3 4 5 6 7 8 ... 31
1
Thanks guys!

Since the original post I've putzed at it a bit more; got it to run around 5x faster than I originally had it (still with interpreting, not compiling all the way to native code). While this sounds cool, an improvement from 1FPS to 5FPS still isn't actually that motivating haha. At some point I might try to strap LLVM to it and see if I can "JIT" it that way (running in-process keeps me from having to deal with cross-platform dynamic loading issues etc), but for now I guess it'll be on hold. Or maybe I'll fill in some more of the API, just to kill the time :D

Anyways, glad you guys thought this was cool, it's been super fun for me as well :)

2
C / C++ /C# / Re: Vulkan is here!
« on: February 26, 2016 »
At first I figured vulkan would be "just another api" but the more I read about it the more I like it. Having lower-level access to the hardware and a smaller API surface are both awesome benefits, though the external sync stuff looks a bit finicky (at a glance).

That said, the bigger problem (at least in my case) is lack of api/driver support, especially for OS X. While the API may be rad, if I can't use it, I won't :)

3
Hey guys! A couple weeks ago I was thinking about projects I was doing when I was younger, and about all the super fun stuff I was doing in Blitz BASIC ~10 years ago! Making demos and sharing them on various forums (including this one) was literally my favorite thing, and Blitz made it all possible! (not to mention the awesome community ofc!!!)

Anyways, I lost most of my files when I left a hard drive on an airplane some years ago (doh!). But I dug around a bit and found this post, which still has the source to my old 3D Overload demo. So I downloaded it and started reading; too much fun! I mean, the code is... "unique" at this point, but I'm still super proud of it and what it meant to me at the time.

Needless to say, I _had_ to get it running. Problem is, I'm on OS X most of the time these days, and didn't feel like setting up a virtual machine and trying to find a compiler. But then I had another fun idea - why don't I just make a compiler/interpreter and run the code that way? Then I get it running on native OS X, and a super fun project to build along the way!

So, fast forward a couple weeks, and I've finally started to get actual code running! I don't have 3D Overload going yet, but after some more digging on this forum and the archives of the old DBF board I found some other effects I made from around that time, so I've been testing with those simpler ones first. So far, I've been able to get my old anti-aliased vector bobs effect running (thanks Shocky for posting that way back when, otherwise I probably wouldn't've ever found it again!), as well as an old plasma.

I call the project "butterball", and you can find it all on the github repo! Unfortunately it's source-only, but if you already have/download the rust compiler (it's written in rust) then you should have no problems getting it to build.

Also, since this is just a toy and not really a serious compiler, it's currently _EXTREMELY_ slow. I find it super ironic that I wanted to move away from Blitz back in the day so badly because it wasn't fast enough, and a decade later I come along and make it even slower XD I have some ideas for how I can improve it ofc and I'll continue some work on it, but I'll still probably continue to interpret the code rather than compiling to native so I don't think the speed will ever be blazing, but I think it can at least recreate the speed this code ran on the machine I wrote it on!

Also, if you try it on some of your own code, it's very likely it won't work. The parser (at least) has been pretty specialized based on the code I'm using to test; I don't plan on being very rigorous about it beyond that :)

Anyways, just had to share this thing; figured you guys would appreciate it :) And finally, some screenshots!


4
well I officially just missed the deadline :D

For those who are curious:

I decided in the last few hours to try to contribute, with a simple "tiny snowflakes fall down and accumulate at the bottom of the screen" effect, and also use the entry as an excuse to learn the Pebble SDK and see what it's like to use Rust on embedded devices!

Needless to say, using Rust like this is quite a pain atm; at least when you can't pull in the standard lib. Or perhaps I just don't know how to do that properly :) . Probably should've skipped the Rust part and made the app in C first... would've been much easier :D

On the bright side, I did manage to get a nice little starting point working for anyone else who wants to play with the Pebble from Rust (unfortunately it's not available on Windows, but it might be useful anyways).

The full attempt is on Github if you wanna check it out; I'll probably finish it one of these days. Or perhaps not, as it was all in all a VERY frustrating experience :D

Good luck to everyone else who entered; this turned into quite the interesting afternoon :D

5
Projects / Re: D-BUG 136A
« on: June 18, 2013 »
It's actually pretty rad how accurate these remakes are, props for that :D

6
General chat / Re: Fun with l.e.d.s
« on: May 20, 2013 »
Haha, nice one :D

7
C / C++ /C# / Re: [C++][Crinkler][glut]
« on: April 16, 2013 »
Quote
I must admit it looks tempting but I strongly suggest not to do it that way.
It just doesn't make sense to put linker settings into the source code.
And it's a terrible pain to fix relative paths if you ever decide to restructure a bigger project.
+1!

8
C / C++ /C# / Re: [C++][Crinkler][glut]
« on: April 16, 2013 »
Ah, I see; then let's solve the real issue instead :)

Are you building GLUT from source, or have you obtained a binary (.dll/.lib pair)?

If you're building from source, I don't think there should be any problems just popping the source in your project and firing away. In this case, uploading the project (or some simplified version of it) would be quite helpful, as someone like Raizor would be able to take a look and help you out for sure.

If you have a .lib & .dll from somewhere, however, then you can't build it all into one .exe without it depending on the .dll in the end. In this case the .lib just contains information about available methods in the .dll, and doesn't eliminate the dependency on the library at all, no matter which linker you use. So, if you really need GLUT, try building the source with your project or to a static library and link that in, or consider eliminating GLUT altogether.

9
C / C++ /C# / Re: [C++][Crinkler][glut]
« on: April 16, 2013 »
Also, you should be aware of the fact that GLUT isn't system-standard on Windows, and should probably be avoided in case of a 4k.

10
oh, and congrats on starting the new synth :)

11
Quote
but as a matter of fact I don't mind working more to get a better result
Good for you :) But don't be so quick to assume anything done in C can outdo anything done in any other language ;)

12
c# for me for nearly everything these days :)

13
Challenges & Competitions / Re: 2013 UDG Challenge!
« on: January 07, 2013 »
can't promise anything these days, but there's a seed planted in the back of my head for it for sure :)

14
Challenges & Competitions / Re: 2013 UDG Challenge!
« on: January 07, 2013 »
<333333333333 !!!!111

Love this concept!!

15
General chat / Re: Recomended web hosting?
« on: November 08, 2012 »
http://iamferris.com/ is hosted by BlueHost. I would love to tell you how I feel about them, but seeing as I haven't yet done shit with the site, I have no idea. It was, however, really simple to set up the domain etc.. but I suppose that's another issue :)

16
General chat / Re: Sundown 2012
« on: September 20, 2012 »
Awesome writeup, k++ :) Congrats on 3rd place and joining Fnuque too!! Those guys are fantastic. Looking forward to more stuff from you in the future, and hope to see you at some party sometime soon :D

17
Projects / Re: HLSL Tunnel
« on: June 25, 2012 »
she's a beauty :)

18
C / C++ /C# / Re: C# GM.DLS Parser (with source)
« on: June 24, 2012 »
Awesome stuff!! K++ of course :)

19
C / C++ /C# / Re: C++ Calling Conventions
« on: May 31, 2012 »
How much do you know about how the specific conventions work under the hood? From what I remember, cdecl is pretty simple; caller pushes arg's on stack in reverse order, callee handles creation of new stack frame and preservation of ebp/esp (including "cleanup" work for the original argument pushing). fastcall afaik is the same except the first two arguments go through ecx/edx for speed. Anyways, I think it really depends on context as far as size; fastcall should be faster in a general sense unless for some reason the arguments were already available on the stack, which is highly unlikely (but a trick used in some 4k stuff I've seen around).

Honestly, though, I think at 64k it's a bit overkill to worry about such things, as it DOES (in my opinion) make the code a bit less readable for perhaps 2-6 bytes gained per function body (not to mention you're also locking the code to x86 by explicitly setting any conventions). At 4k in asm, however, I often drop conventions all together and define them per-function; for instance using FPU stack for arguments where possible for simple routines. The only time it really matters at that level is interop between non-asm code, in which case cdecl is quite straightforward and easy to target.

20
I also have a question about vsti's. How are non-automatable param's set up, and how does midi-interaction work? What sort of methods do you implement for these? (sure this stuff is probably easy to find but it's even easier to ask :) )

Pages: [1] 2 3 4 5 6 7 8 ... 31