hi people

I have to write my computer science thesis next semester. I was thinking about making some 2D game in C, because I love the programming language C.

I have the following idea: instead of exporting and importing spritesheets into my game, I'll write a tool that transforms an animation into pure C code. my intent is to work with vector-based animations, possibly with tweening. when my game loads, it'd pre-render every sprite and visual asset according to physical display resolution and framerate and user quality settings. I'm currently generating game builds for Windows, HTML5 and Android APKs.

I've played lots of games that pre-render stuff when loading, so I guess this is common practice and arguably okay. but I don't know. maybe a cutscene should be rendered and played in realtime? mysteries.

my game would be some kind of 2D side-scroller, probably a shooter or beat-em-up game, or an adventure point-and-click adventure. characters with bones and reverse kinematics is currently out of question. physics is possible, since there is one powerful 2D physics engine for C called Chipmunk2D.

I'm currently exploring the idea of working with SWF. it seems that many animation software exports to SWF, so I suppose this facilitates collaboration with animators. I also saw that there are many tools to render SWF, so I can look at their source code and figure out how they work and replicate their techniques. I think SVG is very heavyweight, but because everything will become C, I could parse it as well. I thought about writing individual plugins/extensions for each animation software, but that sounds like an enormous hassle.

I don't know how to lay out the game levels, like position enemies, spawn points and special interactions. I suppose one could add some metadata inside the animation software, which I could later read to give special meaning. same goes for collision, I suppose the animator could draw some invisible layer that I can interpret as collision.

now, for some technical stuff. I'm using SDL2 or SDL3. as for vector art, there are many libraries that render vector graphics. for software rendering, I can employ OpenMP to use all CPU cores to pre-render stuff. if I use a GPU library, I'd have extra work exposing SDL's GPU APIs to these libraries, but maybe it is worth it.

I'll document here my progress while I experiment and learn from any feedback. I will also keep my discoveries in a PDF that I will update regularly and maybe share here.

there is a lot to learn from existing technology. all of this is preliminary

I don't have any coding experience but it sounds like you want to use bones. This video seems to be doing what you're describing and will probably help.

Okay, I'm going to give you some advice, avoid a proprietary undocumented format like SWF that will burn you out quickly. Either use an open standard or make up one yourself.

I heard about Spine before. it has impressive demos, and it provides one implementation for SDL2 out-of-the-box. I will definitely create a demo exploring is capabilities as a first step.

I don't agree with you

1. "proprietary" is not a turn off for me. I understand SWF was monumental to make possible anti-aliased high-definition images and animations with very high efficiency, so what is the problem? even with problems, it was pioneer work, it's okay to make mistakes when you do it first.
2. "undocumented". Wikipedia says that Adobe published some specifications for SWF, which seem quite readable. these do not reflect latest changes, but maybe I just need earlier well-specified features to handle most common animations. also, it seems that over the years many SWF parsers have been written, so reusing them might be enough to satisfy my use case
3. "burn you out quickly" sure, but how?
4. "open standard" such as SVG? plus CSS? there is plenty of technology around SVG, so I will definitely explore it. but how many animation editors export to SVG? maybe with a plugin? would I need to embed an entire Web browser constraint engine inside my game in order to render SVG animations? also, sometimes open standards are not good, such as the HTTP2 fiasco, so it might be better to adhere to a de facto standard.
5. "make up one yourself" this is very outright wrong advice. never make stuff yourself. I'm an comp-sci undergraduate who is just starting with animation, not an Adobe engineer with 20+ years of experience. there is no way I can conceive any useful format. always adhere to standards, even if they are bad. this article discusses in length about adhering to standards

Chill dude. It's all good.

It's chill and all good man. I think you might misunderstand @xeiavica. At the risk of putting words in his mouth, I think what he means by "your own format" is the internal representation used by your runtime itself. You're right in that you need not attempt to turn this into a file format or standard, you can literally dump and import binaries.

 My own unsolicited two cents is that you should not worry about making the import process "clean". You should feel free to have completely separate programs that--for example--read in SWF and output your internal representation. By being independent these import programs will be free to have completely independent dependencies and build processes. That will save you much heartbreak, I guarantee.

As a concrete example, you could build on top of Haxe's mature SWF integration.

And while I'm seconding other's ideas, you should def look at Spine.

well this is kinda very obvious

this is exactly my objective!! <3

about Spine.

I successfully built its C and SDL runtimes and copied their example into my experimental program. it compiles without errors and runs without errors, but nothing shows up in the window!!

I have to study for a test I have tomorrow, so I won't debug it until next week

even if I'm able to debug it and make it work, Spine has this license thing, so I will only be able to show screenshots for now. even though I could make a Web build and put into Newgrounds Dump, its license forbids it, and that's okay

anyway, Spine seems very impressive, its code is seems to be of high quality and its goal is very clear. I'm very open to the idea of buying a license and make stuff with it if I find artists who know how to export Spine sprites. I haven't read the entire Spine license yet.

I made a mistake with delta time, the example actually works lol

[webp won't play, but it works, trust me]

SDL_SetHint(SDL_HINT_RENDER_SCALE_QUALITY, "2");

this is not present in the example, so everything is jagged.

adding this before initializing SDL enables anti-aliasing out-of-the-box:

great!

Excellent progress! Please keep posting, I'd definitely appreciate Spine'ing vicariously through you.

besides Spine2D, I found two additional competitors:

1. Spriter: https://brashmonkey.com/spriter-runtime-apis/ offers a generic C++ runtime with one example for SFML
2. DragonBones: https://dragonbones.github.io/en/download.html#runLibrary supports C++ runtime specifically for SFML and Cocos2d-x

I haven't looked which editors export them, what are their features, what are their file formats etc.

edit: some discussion regarding exporting stuff: https://github.com/opentoonz/opentoonz_docs/issues/152

I managed to compile swftools, which was last updated 8 years ago:

https://github.com/swftools/swftools

then I downloaded the SWF for this classic submission:

I ran swfdump -D on it, and I have some preliminary conclusions

first of all, I now know my challenge is two-fold:

1. exploit infinite resolution from vector graphics
2. exploit infinite tweening between frames

however, briefly reading the dump, I now realize:

1. SWF has fixed framerate
2. SWF contains thousands of simple commands drawing lines and curves and filling in fixed positions

brief Google search shows that framerate is defined when compiling the FLA, however I'm wary of delving on FLA or any other modern animation software source files, because working with simple commands such as lines and arcs is so much easier for a short-term prototype. furthermore, since some see tweening negatively, that is one more reason not to focus on it.

https://www.newgrounds.com/bbs/topic/1463675

hence, my current goal is to compile those simple SWF commands into hardware-accelerated source code functions and try to play parts of existing SWF in a C program

I think this is a very neat summary of Flash software landscape:

https://en.wikipedia.org/wiki/List_of_Adobe_Flash_software

first of all. licensing. I decided my compiler will be free software with an exception to allow the generated code to be unrestricted, so that any games or other applications can use it, even if proprietary.

that being said, the compiler will be largely divided in two parts:

1. the SWF parser, which is a problem that has been solved several times
2. code generation, which I must do on my own, or be very careful with licensing when reusing code

there is three major libraries to parse SWF:

• https://github.com/ruffle-rs/ruffle/tree/master/swf (created for Ruffle)
• https://lib.haxe.org/p/swf/
• https://github.com/HaxeFoundation/format/tree/master/format/swf (used by Swivel, OpenFL and Lime)

I could also rummage whatever is used inside the following:

• Lightspark (older Ruffle alternative nobody talks about)
• ffmpeg (used by Pencil2D I think)
• swftools

however, I first have to whip out a quick demo ASAP, even if very crappy. so I'm tempted to use gameswf or swftools, which are super old projects that I might be able to adapt quickly because I know C and they are written in C

furthermore, I'm wary of my teachers, so I will a include a SVG parser in this early prototype for the sake of appealing to common sense.

the programming language of choice will be one of Haxe, Rust, C++ or C depending on which SWF parser I settle on. I'm only familiar with C, so anything else will be a learning curve that sacrifices time I don't really haves, so it has to be worth it.

TL;DR I didn't make any progress so far

hey, I have a prototype:

https://www.newgrounds.com/portal/view/project/6419340

more to come

first of all. this is now officially my thesis!

second. the creators of SWF are either insane or mad geniuses. as I dig the format, I'm more and more dazzled. I'm reading about fill styles and their approach is ludicrous. every little thing I learn send shivers down my spine.

I feel like a caveman from the future after a civilization shattering apocalypse, trying to figure out some alien technology from the past. I barely understand the magnitude of the stuff I'm dealing with, or the challenges that await me.

I also found a new competitor: https://rive.app/

they produce three things: an authoring tool, a file format and a software runtime. I detest plain text file formats, specially those built on top of JSON or XML, so their file format being binary definitely feels like a move forward.

finally. I will now keep statistics of features used by There She Is!!! and other Flash movies being tested to direct my development efforts.

first semester I failed both my thesis and Calculus B

no matter, this semester I enrolled in both subjects again. my thesis is exactly the same. I'm also failing Calculus B again

here's a table I've just finished, I'm proud of it. the data is generated automatically, such that every time I implement a new feature, I can regenerate the table to see how much more inefficient my solution has become

this week or next week I'll do a mandatory presentation to the committee to evaluate my progress. it will probably be a bloodbath. I'm looking forward to it

I found another competitor!!!

https://www.gafmedia.com/

looks really cool

https://assetstore.unity.com/packages/tools/animation/gaf-free-flash-for-unity-13593

hey fellas

I've fixed some matrix transformation skill issues

I'm focusing on generating PDF files from Flash files using Cairo, because then I can have vector illustrations in my thesis text rather than screen captures

here's one example:

https://www.newgrounds.com/dump/download/32f683c14f2fd922e700ed134d3d2bc7

which comes from the frame 1817 of this animation:

next up, I will do fills... first solid fills, then bitmap fills, then gradient fills

some updates

my thesis about Flash Player was approved with 8.22/10, I still need to finish Calculus B next semester before graduating

I implemented solid fills, but I failed to implement bitmap and gradient fills

I temporarily dropped support for PlutoVG and HTML Canvas and now only Cairo works, but it successful exports Flash frames into vector PDFs, which is neat.

besides generating C code, I can also transform Flash animations into JavaScript, but this feature is temporarily broken. my approach is so generic, I probably can generate code to any language I want, so support for languages without bindings will be trivial.

my repo is an absolute mess right now, so its online copy at GitHub is outdated, gotta upload my progress eventually.

until the end of my vacation intend to make an online 3D demo where some classic animations play in some floating 3D frames in a dark room, sort of a gloomy museum, showcasing real-time vector rendering. maybe I will do a lazy stickman game to exercise my tool realistically

fun fact. the animation above generates a C source code that weighs 78 MB, totaling 999634 lines of code, almost one million lines of code. that's a lot!!!! it takes so long to compile, I never really waited it finish compilation, but my experience shows that the average TU doubles the size of original source code, so the corresponding TU would weight circa 160 MB. it's my heaviest test case so far.

my project will probably outgrow Flash, I will probably write plugins for every animation editor to export C code directly