GDR Forum Index
Podcast Podcast
Dev Dev Logs
Search Search
RSS RSS
Register Register
Log in Log in
Reply to topic GDR Forum Index -> Game Developer's Refuge -> Development Log - Smiles 2015 (Smiles HD for Steam)
View previous topic :: View next topic  
Author Message
PoV
Moderator

Joined: 21 Aug 2005
Posts: 10584
Location: Canadia
PostPosted: Sun Jan 04, 2015 12:06 pm    Post subject: Development Log - Smiles 2015 (Smiles HD for Steam) Reply with quote

As I mentioned in another thread, Smiles HD was recently greenlit on Steam. This was a game I originally created back in 2008. It launched for iPhone in October 2008 as just "Smiles", won some awards (IGF Mobile 2009 "Best Game" Finalist), I ported it to many other platforms (some as Smiles, most as Smiles HD), and won more stuff (some cash prizes and a Car).

The last real port of the game was in September 2012, which I did a Windows 8 Metro port (i.e. DirectX 11), showed it at a conference (Intel's IDF), but never released it. Over the past 2 years I've done very minor updates to the Metadata of the Android version (to support more devices), but no actual changes. It's the exact same binary.

So it's 6 years later, 2 years since I did anything real with the source code.

In the next 2 weeks, I'd like to ship 3 versions of the game: Windows, Mac, and Linux, for Steam... because you don't say NO to Steam. ;)

* * *

6 years ago when I made the game, I was a Windows user. Today however, I'm a Linux user (Ubuntu). 2014 was my first year as a full-time Linux user, and I have no regrets. For my day-to-day, I'm happier working in Linux. It's not perfect, but I don't have to think about Microsoft bullshit anymore (at least not every day).

A couple days ago, I finally bought a new Laptop, the Lenovo X230 Tablet I was blagging about. It's a wonderful device with Touch, Wacom pen, and good IBM TrackPoint, but I dropped in a 500 GB SSD so I could dual-boot Windows and Linux. I'm in Linux right now, but I'll be jumping back to install some things on Windows soon.

* * *

I've been using SDL2 some years now. When I first switched from SDL1, things were a little buggy, but could be made to work fine on Linux and Windows. Things did eventually get more stable, but it was mostly after I'd finished with my Smiles ports. I believe I have a version of Smiles HD that runs on Windows, built with MinGW and SDL2, and even supports Touch. And throughout its history, I have done ports of Smiles for both Linux and Mac, but I don't even know how long ago that was.

So for the upcoming Steam port, I'm planning to do what I'd like to call a "Clean Port". I'm going to disregard the entire legacy, the unfinished Sony PSP port, and so much legacy code like WebOS, Bada, Nokia Symbian, Marmalade, and so on.

Fun fact, I've been working out of the PSP branch in my codebase for... heh, way too long. ;D


The Clean Port will start with a fresh (from scratch) SDL2 port. I'm going to take various pieces from my current codebase (Stache), and use that to build the new one. I'm going to take the old game code, and adapt it to my new code.

Some bullet points:

- Use the latest SDL2 (I like working from the repo, so I can do bugfixes)
- OpenGL 2.x (i.e. Shader OpenGL, because I just can't go back to shaderless)
- conform to OpenGL ES 2.0 spec (because I always do)
- Mouse and Touch input
- (will probably) switch font code over to my new font code (the old font code I hardcoded everything, and manually made texture atlases)
- (will probably) have to upgrade some of my menu code here and there, so I can do:
- Steam Leaderboards and Achievements.
- Optional: If I get enough (any) reports of people unable to play the game because of OpenGL drivers, I may use Angle (i.e. a fake OpenGL ES 2.0 driver that actually uses Direct3D 9 behind the scenes)

Basically, I want this to be a legit Steam port. Not something that covers the Total Biscuit spectrum of super-options-menus, but something that does everything it should.

- Visual Studio 2010 for Windows port (I typically use MinGW, but there are reasons to prefer MSVC for Windows releases)
- Valve's GCC setup for Linux ports (32bit and 64bit)
- Probably XCode for Mac port (I still need to read Valve's Mac documentation)

For my own sanity, I'm sure I'll still use my local Ubuntu version of GCC for development, and perhaps MinGW for a basic compatibility test.


I'm undecided if I'll actually use them, but I expect that I should be able to make proper non-steam installers. I was about to say I wouldn't know where to use them, but I guess I could get in touch with the Humble Store.

* * *

The game was originally designed for the original iPhone, meaning certain decisions were made to maximize performance there. When I did the original HD port, I had to remake much of the menu artwork. What I have *should* work, but I am expecting some work to make it feel like a good Steam port.

Controller support is on the Wishlist, but I'm fairly certain I wont do it this time. I have a prototype Steam Controller, but nobody else does, so aside from basic support I probably wont do much here.

Some day I may update the mobile ports using the same codebase.

I'm also toying with the idea of adding Steam Workshop support, so people can make (and sell) their own tilesets. I would kind-of like to make the game in to a "Gold Edition" first, redoing the menus, add a very short tutorial. I'm not really interested in making a sequel, but I could probably fix the game.

* * *

One more thing I need to do: I need to get my local server up and running again.

So I moved to a new apartment back in the summer of 2014. Before I moved, I finally noticed that my local server was incorrectly set up. The hard drives were formatted in such a way that Disk Access was INSANELY slow (i.e. misaligned blocks). It took me a month, but I was able to copy all my data off the server on to an external drive (which reads/writes WAY faster). I reformatted the server, copied some files back, but although the performance had improved, it was still not great. It seems I need to do some wizardry when I format the server to correctly align the blocks, wizardry I never got around to doing before I moved, and thus the server has sit idle and unplugged for the past 6 months.

In the summer of 2013, I finally started using a DVCS, Mercurial, hosted on BitBucket. Unfortunately, all my old Smiles code is in Subversion, on that local file server. I still think SVN has its place (assets), but I accept the mantra that a DVCS is better for code. Mercurial is effectively the same as GIT, but I really like revision numbers, so don't even try to tell me I should be using GIT instead. :P

So, if I can motivate myself, I'll hopefully be getting the server working today (if not tomorrow).

Anyways, I'm going to reboot now so I can install Visual Studio.
_________________
Mike Kasprzak
'eh whatever. I used to make AAA and Indie games | Ludum Dare | Blog | Tweetar
View user's profile Send private message
Sirocco
Moderator

Joined: 19 Aug 2005
Posts: 9330
Location: Not Finland
PostPosted: Sun Jan 04, 2015 12:26 pm    Post subject: Reply with quote

Cool. This will give you fresh momentum with a clean code-base. Since you're maining PC this time around, are you going to tweak the menu layouts? There's nothing broken about them, but they're obviously phone-centric.
_________________
NoOP / Reyn Time -- The $ is screwing everyone these days. (0xDB)
View user's profile Send private message Visit poster's website
PoV
Moderator

Joined: 21 Aug 2005
Posts: 10584
Location: Canadia
PostPosted: Sun Jan 04, 2015 12:42 pm    Post subject: Reply with quote

The initial port will probably be mostly the same (PC's have touch too), but I'll probably end up re-doing all the high score and achievement screens.

I picked up this $99 Windows 8 tablet with a 7" touchscreen during Black Friday ... on a whim mind you. But I'd like to make sure running the Steam version of Smiles HD runs as well there as the Android version.

The Steam port will NOT be a Metro port, but I'd like it to be as featured as a Metro port (i.e. accelerometer support).


I don't know what my minimum spec PC is going to be, but requiring OpenGL 2.x means it wont work on some of the older Netbooks I have with the Intel GMA 450 graphics chip. That GPU should die though, so it's only fair. You can't even buy those anymore. Everything sold today (except the 3DS, but you do have some low-level controls there) supports shaders.

Heck, even the Raspberry Pi supports shaders, and it costs as little as $25. The Chromecast, if you were allowed to reprogram it, the GPU does shaders.
_________________
Mike Kasprzak
'eh whatever. I used to make AAA and Indie games | Ludum Dare | Blog | Tweetar
View user's profile Send private message
PoV
Moderator

Joined: 21 Aug 2005
Posts: 10584
Location: Canadia
PostPosted: Sun Jan 04, 2015 5:46 pm    Post subject: Reply with quote

I've hit one snag. I thought I had Visual Studio 2010, but I completely forgot that I actually have Visual Studio 2008 (and 2012, and 2013), but no 2010. :|

Ah well, I'll manage.
_________________
Mike Kasprzak
'eh whatever. I used to make AAA and Indie games | Ludum Dare | Blog | Tweetar
View user's profile Send private message
PoV
Moderator

Joined: 21 Aug 2005
Posts: 10584
Location: Canadia
PostPosted: Sun Jan 04, 2015 6:25 pm    Post subject: Reply with quote

I'm going to try using Visual Studio 2013. Reason:

It appears that mainline Premake (premake-dev) supports it.

https://bitbucket.org/premake

Visual Studio has some pretty bad project management (no two files with same name), so I'd rather generate the project from my build scripts.


Checking in to SDL2, the installation wiki page is exciting.

http://wiki.libsdl.org/Installation

Apparently SDL2 finally has an Emscripten port. This makes me very happy. https://kripken.github.io/emscripten-site/

There's also the WinRT (Windows 8) port. I'm not sure how mature it is, but it's good to hear this exists now.


Most importantly, it sounds like you can make your Mac binaries with SDL "Unix style", which would make me very happy. No offence X-Code, but I don't actually want to use you.
_________________
Mike Kasprzak
'eh whatever. I used to make AAA and Indie games | Ludum Dare | Blog | Tweetar
View user's profile Send private message
PoV
Moderator

Joined: 21 Aug 2005
Posts: 10584
Location: Canadia
PostPosted: Mon Jan 05, 2015 12:26 am    Post subject: Reply with quote

Past several hours spent downloading, installing, and updating software across many machines.

- Windows 7 has Visual Studio 2013 Pro installed (7 GB ISO, that failed 2 GB in)
- Mac now has OSX 10.10.1 installed (the latest), up from 10.8 (oops, that's old)
- Xcode 6.1 now installed (latest stable)
- Emscripten installed (Holy cow! They've improved everything! Even has SDL2 support now! If only installation was faster. ;D)
- Sketchbook Pro is now installed too (what I made the tile art with)
- had to switch my Linux Graphics drivers over to pre-release ones to fix some Ubuntu 14.10 problems.

TODO:
- plug in server
- push all SVN changes to server
- backup server
- reformat and fix the dang drives in the server!
- do software updates on Windows 8 Laptop, and the cheapo $99 Windows 8 tablet
- get Visual Studio installed on the Win 8 laptop, in case I get inspired to do a build
- do updates on Steam Machine (haven't booted it in a while)
- backup iPad, upgrade to iOS 8 (currently iOS 6)

- fetch code from server
- create new repo (Mercurial)
- get something building on all platforms
_________________
Mike Kasprzak
'eh whatever. I used to make AAA and Indie games | Ludum Dare | Blog | Tweetar
View user's profile Send private message
Gil
Developer

Joined: 14 Nov 2005
Posts: 2341
Location: Belgium
PostPosted: Mon Jan 05, 2015 5:43 am    Post subject: Reply with quote

I'm super looking forward to this. I had this "D'oh" moment after it was greenlit where I realized that didn't mean I could play it yet on PC.

My girlfriend just bought a Lenovo n20p Chromebook which would be perfect for it too, but I assume that'd be yet another port?
_________________
PoV: I had to wear pants today. Fo shame!
View user's profile Send private message Visit poster's website
PoV
Moderator

Joined: 21 Aug 2005
Posts: 10584
Location: Canadia
PostPosted: Mon Jan 05, 2015 8:45 am    Post subject: Reply with quote

Yeah, that'd be a web port for the Chrome store (or online). That said, it's not entirely a crazy port either, I just haven't figured out how to make money from it. ;)
_________________
Mike Kasprzak
'eh whatever. I used to make AAA and Indie games | Ludum Dare | Blog | Tweetar
View user's profile Send private message
PoV
Moderator

Joined: 21 Aug 2005
Posts: 10584
Location: Canadia
PostPosted: Wed Jan 07, 2015 11:22 pm    Post subject: Reply with quote

I am loving games done quick, but I think I have to hurry up.

Every day more and more games are getting greenlit at a ridiculous pace. My only advantage is I was greenlit 9 days earlier than most.

So far I've only really done setup and homework. I know everything I need to know, and I've taken care of other big things (GDC travel), but its time to get going.

I've set my alarm for early tomorrow. Gotta get serious.


I think I'll reward myself. If I can finish before next Monday, I'll let myself work on the Commodore 64 game every day that isn't Monday.
_________________
Mike Kasprzak
'eh whatever. I used to make AAA and Indie games | Ludum Dare | Blog | Tweetar
View user's profile Send private message
PoV
Moderator

Joined: 21 Aug 2005
Posts: 10584
Location: Canadia
PostPosted: Fri Jan 09, 2015 2:41 am    Post subject: Reply with quote

The slow migration. :) Working out of Mercurial now.

Did some pre-restructuring today. Moved over some of my modern Library code (Core, System). Still need to do Graphics. Making fixes along the way.

I have some custom tools. Binaries of the tools used to be included in the source tree, but not anymore. I now have a script that builds all tools for the local platform.

I also used to use *ONLY* the windows version of the LZMA compressor. Code for the compressor is now included, and built on the current platform, alongside my custom tools.

In the code itself, I created a new state machine that lets you specify Step (every frame) and Draw (can drop frames) functions. I'm hoping to better structure the Smiles code this time around. The original code has a mega function with state-machine checks right in it, and a bunch of weird inline functions that say what code should be run in each state. I've also set up a Change function, for whenever the state changes, you can do hook in to it and do something.

Not much to show, but a reasonable start.
_________________
Mike Kasprzak
'eh whatever. I used to make AAA and Indie games | Ludum Dare | Blog | Tweetar
View user's profile Send private message
PoV
Moderator

Joined: 21 Aug 2005
Posts: 10584
Location: Canadia
PostPosted: Fri Jan 09, 2015 10:32 am    Post subject: Reply with quote

This morning was spent doing VBO/WebGL homework. Though I'm doing PC ports, I'd like to make sure I'm keeping my new code Web friendly.

Vertex Buffer Objects (VBO's) is the GL way of storing vertices in VRAM. Unlike OpenGL ES 2.0, WebGL requires VBO's.

According to my notes, all devices support VBOs, even the Fixed Function ones (some may only support it in Shader mode).


The main problem with VBO's are the cases where you upload some data and use it once (or at most, a couple times). After the frame ends, it needs a new copy. I wanted to make sure that when I use them, that I'm doing it in an optimal way.

glBufferData has 3 usage modes (more in newer GL's, but these are the cross platform ones):

GL_STREAM_DRAW - One Update, Few uses (possible unavailable in shaderless GL versions)
GL_STATIC_DRAW - One Update, Many uses
GL_DYNAMIC_DRAW - Many Updates, Many uses

That said, these are just optimization hints. You can still update the data at any frequency you want, but if your usage/update frequencies don't match, you might be taking a performance hit when you don't need to.

You then use glBufferData and glBufferSubData to perform uploads/updates.

According to this:

https://www.opengl.org/wiki/Vertex_Specification_Best_Practices#Dynamic_VBO

NVidia has a secret optimization. If you call glBufferData with a null pointer first, then glBufferSubData, the null pointer informs the driver than you don't care about keeping the same memory, and the driver can potentially give you new unused buffer if it'll be quicker.

The other option is double-buffering VBO's. This apparently works well on both NVidia and ATI cards (no reports on other GPUs, but it's a safe bet it'll be better than not).


On WebGL:

https://groups.google.com/forum/#!topic/webgl-dev-list/vMNXSNRAg8M

The null pointer trick is potentially a big slowdown, as all buffers must be initialized to zero (where as regular GL can leave the memory filled with garbage).

Also FWIW, Firefox will apparently call BufferData from BufferSubData if it's determined that the whole buffer is replaced.


As far as I can tell, the most optimal way to handle VBOs in a cross platform way is to double-buffer, or simply have a pool of buffers you use/recycle across frames.


As for the most optimal usage mode, it's definitely one of GL_STREAM_DRAW or GL_DYNAMIC_DRAW, but I'm unsure of the effect benefits. STREAM_DRAW may release the memory for all I know, and DYNAMIC_DRAW keep it around.

The performance gains between the two however may not be that much at all, if double buffering. GL_DYNAMIC_DRAW seems the most general (unoptimized except to maintain memory) choice. Benchmarking may be required to come to a definitive conclusion.

* * *

The other thing, Mipmaps.

As of OpenGL ES 2.0 and OpenGL 3.0, glGenerateMipmap has been available. It's a function that generates Mipmaps for you (potentially) in hardware.

https://www.opengl.org/sdk/docs/man/html/glGenerateMipmap.xhtml

GL_ARB_framebuffer_object ideally the extension you want to check for to get glGenerateMipmap. Alternatively, older OpenGL versions have GL_EXT_framebuffer_object and glGenerateMipmapExt. Hopefully, every GPU and driver available today supports the ARB extension, but I wanted to take note just in case.

https://www.opengl.org/registry/specs/ARB/framebuffer_object.txt
https://www.opengl.org/registry/specs/EXT/framebuffer_object.txt

So far I've avoided using it, but now that I'm free of Fixed-Function OpenGL, I may start.


Looking through my notes, on the PC side, it appears that only Intel GMA 950's are missing the ARB version of the extension (they have EXT). Every other video card in my library has it.

On the mobile side, everything, except original Google G1 supports some form of the FBO spec. When in ES 1.1 mode, The Nexus One and Palm devices support GL_OES_framebuffer_object, which provides glGenerateMipmapOES.


Conclusion: It's a fairly safe bet that glGenerateMipmap will be available. All Shader GPUs support it natively (or as the ARB extension). Only if you're on a Fixed Function OpenGL will you have to deal with EXT or OES versions.
_________________
Mike Kasprzak
'eh whatever. I used to make AAA and Indie games | Ludum Dare | Blog | Tweetar
View user's profile Send private message
PoV
Moderator

Joined: 21 Aug 2005
Posts: 10584
Location: Canadia
PostPosted: Fri Jan 09, 2015 11:53 am    Post subject: Reply with quote

Haha! So I was talking with some friends, saying how I'm not expecting more than a few hundred dollars a month for the Steam ports. A friend of mine joked that I should make it Zombie themed for a "500% increase in profit".

I laughed at first (Braaaaiiiinnnsss HD), ... and then I squinted my eyes in thought as I rubbed my chin. :)


I've been toying with the idea of a major update anyway. Taking what I've learned the past 6 years, and (sort of) making a sequel. It's basically the same game, with a few tweaks, UX fixes, and a UI reskin.

If I'm quick, I suppose I could do a reskin of a reskin, Zombify it, and make a combination DLC and Standalone game for Halloween.


Ha! Wouldn't that be funny. :). I just need to KILL my NEED to work on non-Smiles games.

Would be a good exercise for adding and testing MOD support, by doing a total conversion. Ice Blocks become Candy Blocks. :). Rocks become... something more resilient than Candy?
_________________
Mike Kasprzak
'eh whatever. I used to make AAA and Indie games | Ludum Dare | Blog | Tweetar
View user's profile Send private message
PoV
Moderator

Joined: 21 Aug 2005
Posts: 10584
Location: Canadia
PostPosted: Sun Jan 11, 2015 2:32 pm    Post subject: Reply with quote

So I'm contemplating various degrees of MOD support. The very first step to that would be to change/update the configuration format, or at the very least to think about it.

Currently the game uses a somewhat rough serialization format for remembering game state, high scores, and achievements. There are often pairs of functions, one for reading and one for writing, each needing updating whenever there are changes to the format. I forget, but there may be a very basic versioning in the data formats, but beyond failing to read the data if there's a version mismatch, there's no forward/backward compatibility supported at all. That, and game states are hardcoded numbers (enums), so if I'm not careful (i.e. always adding new states to the end), then when a game is resumed it may not return to where it was.

So quickly, I wanted to see what the options were.

The game is written in C++, but I prefer to work with 3rd party libraries (due to less bullshit in how they're designed). IMO the best 3rd party libraries are the ones that are 1-2 files you just include in your project, no wacky build configurations needed. Things like ZLib, LZMA, and anything STB are IMO great libraries.

First off, data exchange formats:

JSON:
http://json.org/
http://sourceforge.net/projects/cjson/

In general JSON is my preferred data format. I'm sure there are better (faster) choices for a JSON parser library, but cJSON is ANSI C and just 2 source files, so that makes it ideal.

cJSON is a very strict library (which is a good thing). I am tempted to fork it and make a relaxed version, the main change being to support extra unused commas in arrays and objects (so you can always trail a manually edited line with a comma, and the parser eliminates it).

YAML:
http://yaml.org/
http://en.wikipedia.org/wiki/YAML

I've never seriously looked at YAML, but I thought I'd at least look. The syntax is a bit like INF files, colon delimited with some added features. To be honest I DON'T like it.

XML:
To be honest, I don't really have an XML library I like. cJSON works by walking nodes using pointers (and it's 2 files). My ideal XML library would be exactly the same. And heck, if it could parse CSS as well (inline or as raw blocks), that would be kinda great.


Next up, "Configuration Languages":

Lua:
Reading the Lua documentation was the first time I'd ever heard this term used. Essentially, Lua likes to think of itself as an XML or JSON on crack, meaning not only can you set and retrieve values, but you can do it programatically as well.

That said, I don't like Lua as a language. Some of the design choices, like counting from 1 instead 0 don't really make things better IMO. It makes it an oddball of a language, having to switch brain modes between it and whatever language you're using.

Python:
No.

Squirrel:
http://www.squirrel-lang.org/

If I do go the "configuration langue" route, I'd probably go with Squirrel, since I both prefer the syntax (JavaScript/JSON like), and I've actually used it in practice (and it's kinda great IMO). It's very flexible and I really like it, but the caveats are that it's somewhat difficult to get data out/put data in to the VM. At least, everything I've done has been through function calls and interactions with the VM stack. It could probably benefit from some cJSON'esc functions for walking memory. Maybe it actually does have them, but this is not something I've tried yet.

Chrome's V8 (i.e. JavaScript):
I did an experiment a long time ago with V8, and it it worked out pretty well. Squirrel is a bit obscure, Lua a bit F'n weird, but JavaScript is common and powerful. In the past I've been somewhat worried about the need for double precision floating point support, but I'm sure I could deal with it. On older devices like the 3DS and some mobile devices performance might hurt a bit, but it means Web ports could actually run native.

I'm not against V8, but the focus there isn't low memory usage and overhead like Lua and Squirrel.


Finally, C/C++ Serialization Libraries:

Cereal:
http://uscilab.github.io/cereal/

I like the pitch anyway. A lightweight C++11 library for serializing arbitrary data structures. The downside however is the C++11 part (that and I haven't look at the dependencies). C++11 is decently supported by ALMOST everything I use (GCC for Linux and Android (?), CLANG for Mac/iOS and Web/Emscripten, MSVC for Windows). The problem is of course consoles, which are still on the table (though of lower priority). Xbox One isn't an issue (I don't think, not that I care), Nintendo definitely is an issue (obscure compilers for both systems), and Sony *probably* is but I don't really know (last time I did Sony dev was PSP). So as much as I'd like to consider Cereal, I shouldn't, not as long as I care about consoles.

Google Protocol Buffers:
https://developers.google.com/protocol-buffers/
https://github.com/google/protobuf/
https://github.com/protobuf-c/protobuf-c

I haven't looked too closely at this, but it already gets bonus points for having a C version. After I post this, I need to quickly give this a read.

Custom:
Or just do something custom.

What I do right now in Smiles is basically populate a structure in memory with a copy of the real data. In some cases (achievements), I actually use the same raw memory layout as what I write to disk. That means I can literally fwrite the memory block as-is. This is nice. It's a bit of a pain in the arse to structure your code so that it can be written in this way (i.e. you can't use pointers, or rather you can't depend on them), but It's convenient and C compatible.

PHP's serialization features are excellent. It's a simple matter of passing a thing you want saved/loaded, and it just works. Unfortunately that's by design, something the developers intended when they created the language, and in practice it's wonderful. This isn't something that's easy to achieve with C/C++, but Cereal does give me some hope.

Jonathan Blow has been talking extensively about a programmer benefiting language for some months now, and has implemented something that has made him happier. He's a bit of a hard-ass C/C++ programmer, which admittedly I am too, but I'm more willing to see the upsides of JavaScript and PHP, since I've done real work in both. Fundamental to both languages is the idea of variable types, i.e. variables that can be strings one moment, integers another, or booleans another. What's key however is that you both know and can check the type of a variable at run time. It's not necessarily polymorphic or reflective, but for the cost of 1 extra pointer attached to every variable (and all built-in types having a real instance), we can check the type of a variable VERY quickly (basically 1 compare opcode). In my opinion that is a reasonable trade off. An extra 4 bytes (8 bytes on 64bit OS's) to be able to know exactly what type a variable inside a structure or type is a good deal. I'm not even talking about doubling the data usage. A structure would still take up the same amount of memory per instance, but there would be a layout somewhere that said what each part was, and you could walk that layout to easily implement a serializer. Alas, this is a fundamental language feature, and something I'm pretty sure Jon will not tackle in his language. It's such a shame that only Garbage Collected languages support this wonderful feature.

One possibility would be to adopt a coding style that simulates this. I.e. Create a global structure for much of your game/state data. At the same time, maintain an array that lists all types in the data, and walk that array when attempting to serialize. You might even be able to automate this if you had a good library for parsing/tokenizing C code. Sounds like work though. ;)

Alternatively: avoid pointers, or write custom code to handle them in your your serialize functions.

Worth mentioning: None of these deal with backwards compatibility.


Anyways, I want to quickly look at the Google option, just to see what they do, and then I'll decide. Bottom line though, as much as "Full MOD support" is desirable, at least for this game, just adding hooks to customize may be enough.
_________________
Mike Kasprzak
'eh whatever. I used to make AAA and Indie games | Ludum Dare | Blog | Tweetar


Edited by PoV on Sun Jan 11, 2015 2:52 pm; edited 1 time
View user's profile Send private message
Gil
Developer

Joined: 14 Nov 2005
Posts: 2341
Location: Belgium
PostPosted: Sun Jan 11, 2015 2:52 pm    Post subject: Reply with quote

I like YAML for being human-readable, but I agree it doesn't quite feel right. I wonder if Markdown would be a valid option for data storage/transfer. It's even more readable than YAML and it's way simpler.

PoV wrote:
I'm more willing to see the upsides of JavaScript and PHP, since I've done real work in both. Fundamental to both languages is the idea of variable types, i.e. variables that can be strings one moment, integers another, or booleans another. What's key however is that you both know and can check the type of a variable at run time. It's not necessarily polymorphic or reflective, but for the cost of 1 extra pointer attached to every variable (and all built-in types having a real instance), we can check the type of a variable VERY quickly (basically 1 compare opcode). In my opinion that is a reasonable trade off. An extra 4 bytes (8 bytes on 64bit OS's) to be able to know exactly what type a variable inside a structure or type is a good deal. I'm not even talking about doubling the data usage. A structure would still take up the same amount of memory per instance, but there would be a layout somewhere that said what each part was, and you could walk that layout to easily implement a serializer. Alas, this is a fundamental language feature, and something I'm pretty sure Jon will not tackle in his language. It's such a shame that only Garbage Collected languages support this wonderful feature.
I disagree with your assessment of dynamic types and Javascript. Fundamental to Javascript, to me, is the prototypal nature and the simple dictionary/list model they use. It's this same dictionary/list model that makes JSON such a powerhouse. Dynamic types in Javascript seem to facilitate this model, but I consider it secondary compared to the pure raw power of prototypes. Being able to store templates in a variable, making classes first-class citizens and going even beyond that (prototypes in a language with closures are strictly more powerful than classes) is what's novel, not being able to store a boolean in that same variable too. [/rant]
_________________
PoV: I had to wear pants today. Fo shame!
View user's profile Send private message Visit poster's website
PoV
Moderator

Joined: 21 Aug 2005
Posts: 10584
Location: Canadia
PostPosted: Sun Jan 11, 2015 3:11 pm    Post subject: Reply with quote

Fine, I didn't word it right. The point I was trying to get across is that you can always determine the type of something, not that it can be changed (that's just a side effect). Practically, the changing types are useful in functions. Depending on what I get as input, I can interpret it differently. And if I can always figure out what a type is, that makes serialization easy. You can sort-of do it with C++ templates, but it's not as easy to just hack something together (you'll eventually need to overload).

JavaScirpt is a hacking language. You can write some of the filthiest code, and it's legal. Heavy structure and strict types get in the way of run-once/low priority bullshit code.


Anyways, quick look at Cereal, I don't think I like it. It's heavily a C++ streams based library, which is a pain in the ass. I'm sure there's such a thing as a memory stream (memory you can use as a file), as I pretty-much 100% of the time want to output to a block of memory. I'm sure I've used it too, but I gave up on STL's bullshit (i.e. by design how difficult the templates make documentation) years ago. I still use STL strings, but I cringe every time I do.
_________________
Mike Kasprzak
'eh whatever. I used to make AAA and Indie games | Ludum Dare | Blog | Tweetar
View user's profile Send private message
Gil
Developer

Joined: 14 Nov 2005
Posts: 2341
Location: Belgium
PostPosted: Sun Jan 11, 2015 9:18 pm    Post subject: Reply with quote

So many options though :)

This guy at Amazon says you should be using some form of Lisp:
https://sites.google.com/site/steveyegge2/the-emacs-problem
_________________
PoV: I had to wear pants today. Fo shame!
View user's profile Send private message Visit poster's website
PoV
Moderator

Joined: 21 Aug 2005
Posts: 10584
Location: Canadia
PostPosted: Sun Jan 11, 2015 11:24 pm    Post subject: Reply with quote

I just added some features to cJSON. Wishlist stuff (c-style block comments, tail commas).

https://github.com/povrazor/cjson-lax

Looking at Google Protocol Buffers. They actually look like a great solution, but I don't like what the C version outputs. Checking how fat the C++ version is.
_________________
Mike Kasprzak
'eh whatever. I used to make AAA and Indie games | Ludum Dare | Blog | Tweetar
View user's profile Send private message
PoV
Moderator

Joined: 21 Aug 2005
Posts: 10584
Location: Canadia
PostPosted: Mon Jan 12, 2015 8:36 am    Post subject: Reply with quote

So this exists. Embedded Chrome:

https://code.google.com/p/chromiumembedded/

Not something I plan to do anything with in the near term, but it's still interesting to see.
_________________
Mike Kasprzak
'eh whatever. I used to make AAA and Indie games | Ludum Dare | Blog | Tweetar
View user's profile Send private message
PoV
Moderator

Joined: 21 Aug 2005
Posts: 10584
Location: Canadia
PostPosted: Wed Jan 14, 2015 10:34 am    Post subject: Reply with quote

Past couple days were spent reworking (refactoring) my build system (again).

- It's still a bit clumsy, but instead of shipping executables in the source tree, tools are now compiled on demand depending on the target.
- Instead of a large folder of library build settings, compiler usage settings, target platform settings, I've cleaned things up. Target settings are now in their own folder (and multiplying quickly, 20 items right now). Build settings are now alongside the individual libraries (lib.mk). Long story short, understanding what's going on is a lot easier, and it's less of a pain to find what you're looking for.
- the core makefile now supports multiple targets from one build. This is potentially useful for creating a unified 32bit and 64bit Linux build, or just all linux builds at once (general builds (humble store), steam builds, Ubuntu Store, etc).

Builds are currently working on Linux and Windows (under MSys using MinGW).


One thing I'm really happy to see, after digging through the SDL docs, is it sounds like Angle (i.e. OpenGL ES 2.0 ported to D3D) is now the default/recommended way to do Windows ports. I'm hoping to test this out today.
_________________
Mike Kasprzak
'eh whatever. I used to make AAA and Indie games | Ludum Dare | Blog | Tweetar
View user's profile Send private message
PoV
Moderator

Joined: 21 Aug 2005
Posts: 10584
Location: Canadia
PostPosted: Mon Jan 26, 2015 10:56 pm    Post subject: Reply with quote

I'm really behind on this. I've only *just* finished porting some of the graphics code to my new library.




Progress none the less.
_________________
Mike Kasprzak
'eh whatever. I used to make AAA and Indie games | Ludum Dare | Blog | Tweetar
View user's profile Send private message
PoV
Moderator

Joined: 21 Aug 2005
Posts: 10584
Location: Canadia
PostPosted: Thu Jan 29, 2015 11:52 pm    Post subject: Reply with quote

Okay, game is running again.



Input and Aspect Ratio are still broken, and a lot of rendering code isn't finished porting yet, but it looks like Smiles.

- Fixed Blending (also now Premultiplied)
- Generating and Using MipMaps now (Trilinear Filtering)
- Re-added Frameskipping and optimal ordering (less waiting for flush)
- Fixed font code
- Mostly glitch-free window resizing
- Averaging about 8% CPU usage on my Linux Laptop

Could probably use some Multisample Antialiasing to clean up those lines.

EDIT: Note to self: Tegra lacks MSAA, and instead has CSAA. http://www.nvidia.com/object/coverage-sampled-aa.html
_________________
Mike Kasprzak
'eh whatever. I used to make AAA and Indie games | Ludum Dare | Blog | Tweetar
View user's profile Send private message
Reply to topic GDR Forum Index -> Game Developer's Refuge -> Development Log - Smiles 2015 (Smiles HD for Steam)

Use this link to get a Sign-On Bonus when you get started!

All trademarks and copyrights on this page are owned by their respective owners. All comments owned by their respective posters.
phpBB code © 2001, 2005 phpBB Group. Other message board code © Kevin Reems.