Jump to content


Member Since 23 Nov 2013
Offline Last Active Feb 23 2017 11:32 AM

Posts I've Made

In Topic: gallery not working

29 April 2016 - 05:26 PM

Cool.. thanks guys.

In Topic: gallery not working

25 April 2016 - 04:06 PM

Neither of these URLs are working.





Looks like a problem with NetDNA CDN, or maybe DNS. Those subdomains have CNAME records pointing at public.gamedevnetllc.netdna-cdn.com and so on.


It's been 4+ days... it's not a temporary problem that's going to resolve itself.

In Topic: Are bugs being fixed? Or no one reported these?

15 December 2015 - 11:40 PM

Guideline: KEEP IT SIMPLE, oldschool, semi-fugly, not particularly mobile-friendly

Probably the second most common request we get (after fixing the post editor) is a site that works well on mobile. Mobile accounts for such a huge portion of visitors that whatever we choose needs to make at least some improvement in that area; not particularly mobile-friendly just isn't a viable option.


Oh ok, I'm only a little surprised. No big deal though.

1. Keep it simple, no frills, clean layout... a few CSS @media blocks
2. No battery-wasting JS bloat, CSS animations, or 3rd party tracking/sharing/ads/iframes

3. Minimize bandwidth usage & http requests... mainly, combine+minify js/css


No need for the cheesy "mobile friendly" look of the reviled new Invision https://community.invisionpower.com/. They haven't done a very good job of the above, either.

In Topic: Are bugs being fixed? Or no one reported these?

15 December 2015 - 08:24 PM

So this is a slightly(?) customized older version of Invision forum software - no wonder it's been falling apart. (I was guessing Wordpress with way too many plugins, lol)


I think GDnet is too big and long-term to entrust to any canned software suite. I would go for a modular architecture with a few custom modules, something like this:


- Divide into independent parts: Articles, Books, Forums/Journals, Gallery/Screenshots, Comments, Chat, Store, Stats/analytics...

- Throw away all the unused/useless parts (have no mercy ph34r.png .. for example, who needs emoji graphics? use friggin' ascii)

- Guideline: KEEP IT SIMPLE, oldschool, semi-fugly, not particularly mobile-friendly
- Goal: JSON APIs for all database access, with server-side templates for SEO and NoScript users
- Possibility: generate static HTML pages (like NeHe..) for Articles, Book lists, etc (anything not prone to rapid change or obsolesence)

- Goal: JS-based auth, comments, chat, stats (helps to minimize backend integration headaches)

- Goal: common user account/authentication system for all parts that require login

- Goal: use "de facto standard" components (eg. CKeditor?, Markdown?, PLupload, Jinja templates)

- Goal: 100% self-hosted open source code (to simplify maintenance & IP issues)

- Automate the migration process

- Redirect old article/forum/journal/user URLs to new structure

- Migrate, test, and repeat until all essential functionality works
- Cutover and stand by to debug


One thing to watch is the JSON API that Wordpress is rolling out. It's not ideal *but* it'll make it easy for people to write drop-in replacements for parts of WP, which unlike WP could actually be decent. So that could supply the missing pieces, for example, a standalone self-hosted comment system. It might be worth waiting like 6 months to see how all that develops.


I don't know about you guys, but I have very low expectations for web stuff. Makes it easier to build it "good enough", go live, and move on.

In Topic: Fixed-Time step only for physics ?

02 September 2014 - 07:38 AM

Fixed-timestep everything is simple, classic, and best. Preferably synced to video refresh.


I've learned not to bother with variable timesteps or interpolation. It's a lot of complication for little/no benefit.  If you can't quite keep up with 60 fps, you get stuttering. You can smooth it out by skipping a few renders, but if there's more than~30ms lag, let it freeze (unless it's network multiplayer). If it keeps happening it'll look jumpy, so drop your framerate or turn off some effects; 30 fps is better than 55 fps.


If input timing is crucial, you could run several physics updates per render frame, or if possible factor the input event timestamp into your calculations.