|
shodanjr_gr posted:That's what ive been reading as well. I was just hoping for some experimental/proof of concept implementation, but oh-well...
|
#
¿
Aug 25, 2008 10:08
|
|
|
|
| # ¿ May 14, 2024 17:30 |
|
|
ImDifferent posted:we're dynamically generating AS3 code from erb templates on the backend, compiling it, and serving up SWFs which are dynamically linked into the runtime.  (but interesting, yes)
|
|
#
¿
Sep 26, 2008 15:02
|
|
|
fankey posted:Our largest system has a butt load of horsepower What kind of system is it?
|
|
#
¿
Dec 15, 2010 09:22
|
|
|
fankey posted:Q-Sys
|
|
#
¿
Dec 16, 2010 13:07
|
|
|
Factor Mystic posted:Todo: rip off the rest of Now.js's features
|
|
#
¿
Oct 11, 2011 10:18
|
|
|
OneEightHundred posted:Doesn't ASP.NET's WebMethod feature already do that?
|
|
#
¿
Oct 12, 2011 12:14
|
|
|
I've been suffering from a heavy bout of pneumonia recently and I'm finally at the stage where I have at least *some* energy to be active. It still costs quite a lot of energy to wrap my head around the coding and architecture I normally do at work, but I still wanted to flex my coding muscle ( ) and play around with Knockout, NodeJS and...well, Commodore 64.During my recovery (sorry for sounding so E/N) I've been reading a few issues of Retro Gamer and just enjoying Commodore 64 nostalgia. So what better way to combine all this then to: Build a sprite editor using Javascript and NodeJS:  And showing that sprite in WinVICE:  Now if only I could improve my drawing skills...
|
|
#
¿
Jan 31, 2012 12:31
|
|
|
the wizards beard posted:This is really cool. I've been playing with c64 recently as well, if you found any good references it would be great if you could share them.
|
|
#
¿
Jan 31, 2012 13:44
|
|
|
I posted a week or two ago about my c64 sprite editor. I've been doing some more c64 development in the evening, and look at this: It's a 20x12 map (surrounded by debug information) showing an implementation of the A* algorithm. It's not particularly speedy, taking about 1 second to calculate the path, but since it is iterative I can probably get away with using it in a game if I amortize the cost over a whole bunch of frames. Whee!
|
|
#
¿
Feb 10, 2012 14:37
|
|
|
Internet Janitor posted:Sagacity: That's pretty rad. In that kind of situation I'd be tempted to go with a simple flood-fill algorithm over A* because A* normally involves maintaining more complex data structures. Care to go into some detail about your implementation? But flood-fill would probably take even more time. The implementation is fairly straightforward, I basically implemented the "Summary of the A* Method" from here. I have 5 things that I need to store per tile: G (the number of steps from the start), cost (G + H), the open list, the closed list and the tile's parent. Because my map is 20 * 12 this takes 240 bytes per list, so it's 1200 bytes in total, which is okay. Most of the time goes into adding and removing things from the open list. Removing a tile means shifting all subsequent tiles back, which takes a bit of time. So instead of adding tiles to the list, I'm thinking about doing something like openList[tileOffset] = true; That would mean it would take longer to find the lowest cost 'open list' tile though, because traversing would increase in complexity. Oh well. Edit: Yep, the "openList[tileOffset] = true" approach works quite well. It allows me to combine open and closed lists by just saying that "list[offset] = 1" means it's on the open list, and "2" means it's on the closed list. So it saves me 240 bytes as well. Now if only I could avoid the expensive step of finding the lowest cost somehow... Grab the demo here: http://dl.dropbox.com/u/512956/astar.prg Press firebutton in joystick in port 2 to advance through a few routes. Sagacity fucked around with this message at 19:03 on Feb 10, 2012 |
|
#
¿
Feb 10, 2012 17:23
|
|
|
cuatro posted:if your using C++ use a heap 
|
|
#
¿
Feb 10, 2012 19:04
|
|
|
Cowcatcher posted:> brush teeth
|
|
#
¿
Jul 13, 2012 09:26
|
|
|
musclecoder posted:I just launched my first startup/product - Accthub. From your FAQ: "This question has been asked a lot frequently". Isn't that what usually happens with questions that are asked a lot? Also, I don't think you should talk about "getting acquired" at all, btw. The primary focus of that page is to explain what your site does and to be frank I've read it a few times now and I'm still a bit confused as what the hell it is your doing. What I can see it seems to be account management and I'm not sure why I would want to use accthub to do that. What's the added value for me?
|
|
#
¿
Jul 23, 2012 13:18
|
|
|
musclecoder posted:(see the recent Sparrow hullabaloo as an example). Most of these high-profile acquisitions are still flukes, and I think they typically happen when you have a larger userbase than you currently have. I see where you're coming from, but I feel that your homepage copy *at this point* should not be deviating from the main point: Selling your product. musclecoder posted:Basically, the idea is this: say you're building a mobile app that requires users to register and you need to store their data in a central server (a fitness tracking app might be a perfect example). Otherwise it might seem that Accthub is *just* for account management and nothing else and quite frankly every app developer is going to want to store more than just general account data of people (otherwise, what's the point of having accounts in the first place)?
|
|
#
¿
Jul 23, 2012 14:27
|
|
|
musclecoder posted:I really have no idea what I would do if some big company came knocking with a boatload of money. 
|
|
#
¿
Jul 23, 2012 14:43
|
|
|
As I mentioned in the other thread as well (or maybe failed to articulate correctly, come to think of it), is that it feels very lightweight. There's a lot of talk on the site, but if all it does is just track users with some attributes, then that could be useful for mobile developers who just want to add quick account management to their application. However, I don't see anyone running this on their own servers. In a very concrete way, why would anyone use this system over, say, Active Directory or LDAP? Moreover, when I'm doing ecommerce using an off-the-shelf solution or a custom solution, wouldn't I have user management already anyway? How much time and effort would it take me to convert everything to use your REST API? These are the kind of questions that your website leaves unanswered. It talks about how "exciting" Accthub is, but not why I'd want to use it. I mean, one of your bullet points is that you use bcrypt to hash passwords. Is that *really* one of the most exciting features of your system? Sorry if I come off harsh, btw! I certainly wish you the best of luck with this, but right now Accthub seems very light on features and I think that's one of the reasons you're seeing low adoption.
|
|
#
¿
Sep 7, 2012 10:36
|
|
|
musclecoder posted:LDAP or ActiveDirectory would be used for the employees of your company, Accthub would be for the customers on your companies product(s). Other companies will tend to a) use an off-the-shelf all in one ecommerce solution, b) have their user management set up in a separate component anyway or c) have a semi-hacky solution. Your target audience seems to be mostly c), right? I mean, companies that have a lot of hassle with their custom hacky solution and want to replace it with a clean component. I personally feel this is going to be the most difficult audience to sell your product to (if they knew what they were doing they probably had a clean solution already) and, on top of that, you also need them to convert their code to use Accthub, which will mean a LOT of support. It might work if you also provide consultancy along with it, so that it becomes more a "we come in and replace your account management tools and it'll look like THIS" [cue presentation of fancy dashboard graphics]
|
|
#
¿
Sep 7, 2012 11:52
|
|
|
Lots of that music is used without attribution, from demoscene guys. Check out www.chiptune.com.
|
|
#
¿
Jul 21, 2013 22:17
|
|
|
Suspicious Dish posted:So, let me ask you guys: did you understand the material? Or was everything perfect? Should I write less for the next article? Write more? Did I spend too much on basic stuff everybody already knows and then when we got to the complex stuff, "the bottom fell out" and you lost me? Any technical questions left after reading that? One thing that you didn't explain, but maybe that's also outside the scope of your articles, is why certain decisions were made in the first place. For instance, why have an X Server? Why not "just" do more stuff locally? Were the clients traditionally very slow framebuffer-only devices, or is there more reasoning behind it all?
|
|
#
¿
Dec 30, 2013 22:58
|
|
|
I'm sorry, I should rephrase: I was under the impression that the server was historically run on another, more powerful, machine than the clients, but I may have misunderstood.
|
|
#
¿
Dec 30, 2013 23:41
|
|
|
darkpool posted:I have a whole load of stories about this thing, I could elaborate forever.
|
|
#
¿
Aug 5, 2014 12:31
|
|
|
Gah, amazing. I've been working with Haxe for my simple little game as well and I must say I really enjoy it. It's pretty well thought-out and it truly is cross-platform. I would expect having an HTML5 engine embedded in Chromium would've been tricky as hell to get working correctly though, especially when you need to communicate UI events to it.
|
|
#
¿
Aug 6, 2014 12:25
|
|
|
I read it because it's typically a good place to find new stuff. Can you recommend a less bitter place?
|
|
#
¿
Oct 19, 2014 12:42
|
|
|
I picked up a book at a fleamarket around 1996 which does a really good job of explaining all the details needed to build a raycaster.
|
|
#
¿
Oct 21, 2014 16:28
|
|
|
Steckles, you could investigate span buffers if you want to get rid of overdraw but with better cache usage.
|
|
#
¿
Nov 5, 2014 15:46
|
|
|
I've always dabbled in the demoscene and one thing I never got around to building was a GUI that allowed me to create a node graph with every node containing properties that could potentially be animated. The graph is something I could then use to render my demo. This is what I have so far, after about 1.5 week of hacking in my spare time:  I can create and remove nodes and connections, cut, copy and paste them. Also a node can have editable properties (no animation yet). It's been pretty fun to work on. I'm using C++11 for the core engine and I've built the UI using Qt5 and QtQuick which is really insanely powerful. Having done a lot of frontend Javascript for my dayjob (using Knockout) it's delightful to be able to have MVVM and two-way bindings in my native application as well. Also, thanks to CMake I'm developing on Windows but I've been able to get it to build on Ubuntu as well. Not sure when I get around to building an actual demo yet. There's no rendering *at all* yet, it's just the node graph. But at least the foundation is pretty solid. Having unique_ptr and move semantics to clearly manage object ownerships is great.
|
|
#
¿
Nov 14, 2014 12:12
|
|
|
Neurion: That's awesome! It makes me feel like a kid again In my spare time for the last year or so (an evening a week) I've been working on a node- and timeline editor. It should eventually start rendering stuff but for now you can just connect and group nodes, animate properties and so on. Progress is slow, but steady! 
|
|
#
¿
Sep 22, 2015 19:44
|
|
|
Shinku ABOOKEN posted:Neat. What's the GUI toolkit you're using?
|
|
#
¿
Sep 24, 2015 16:51
|
|
|
I was just wondering, is the sound programming one of the things you're just interested in tinkering with and did you also take a look at libraries like this? I used to use this when it was still called Midas Sound System, afterwards replaced it with something called Indoor Sound System (by the guy that did Cubic Player) but for some reason I can't find that lib anywhere.
|
|
#
¿
Jun 17, 2016 10:54
|
|
|
When I was doing demoscene coding in the late 90's (right before accelators became widely used) this article really helped me out. Basically anything by Paul Nettle around that time was gold. This article gives a basis for a pretty accurate (perspective-correct) rasterizer and I think it's a good starting point if you want to do more complicated things.
|
|
#
¿
Jul 22, 2016 09:52
|
|
|
I've been working on a sprite multiplexer for the Commodore 64. It has eight hardware sprites by default. However, because the screen is built up from top to bottom you can deceive its video chip: Let's say we draw 8 sprites in the top half of the screen. If the electron beam of the display is halfway down the image you can then move the sprites to the bottom half of the screen and, as the video chip continues drawing, it will draw *these* eight sprites too! Well, do that with a bunch more elaborate timing (that's the color bars you see, they are for debugging purposes) and you get a 24 sprite multiplexer. Fun!
|
|
#
¿
Sep 30, 2017 16:45
|
|
|
TheresaJayne posted:A friend and I once did a mod player in Pascal on a PC, and a little trick we did was added a surround sound option by taking the channel Left and Right mixed to mono then inverted the right channel...
|
|
#
¿
Nov 28, 2017 16:31
|
|
|
TheresaJayne posted:Sorry for the delay, we didnt release it anywhere - this was prior to the internet being a thing,
|
|
#
¿
Dec 13, 2017 09:28
|
|
|
It would be great to have something based on this
|
|
#
¿
May 1, 2019 10:53
|
|
|
It was some Amiga magazine coverdisk at one point, I believe. It's really fun to play and I wish the concept would be extended 
|
|
#
¿
May 1, 2019 14:17
|
|
|
|
| # ¿ May 14, 2024 17:30 |
|
|
I personally compose all my loops in the key of s
|
|
#
¿
Feb 4, 2021 16:24
|
|