[HN Gopher] Flappy Bird for Android, only C, under 100KB
___________________________________________________________________
Flappy Bird for Android, only C, under 100KB
Author : lostmsu
Score : 276 points
Date : 2024-09-22 04:39 UTC (18 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| freitzzz wrote:
| Really cool! I just love seeing Android apps that weight less
| than a 1MB and run anywhere, even on your old HTC.
|
| Congrats!
| mdp2021 wrote:
| Also an assessment of speed gains would be nice.
| habibur wrote:
| Less than 4k loc. 457 android_native_app_glue.c
| 360 audio.c 802 game.c 201 init.c 93 main.c
| 39 mouse.c 38 shaders.c 229 texture.c 1377
| upng.c 27 utils.c 3623 total
| kgeist wrote:
| A student of mine had an assignment to write a game using SFML,
| they wrote a FlappyBird clone and it was like a few hundred
| lines of code. It's not a very complex program to write. To be
| honest, I think 4k is too much :)
| snvzz wrote:
| To be fair, Android itself requires some level of fluff.
|
| So does making the game work well in more than one device.
| dario_od wrote:
| Are you including SFML loc in that total?
| kvemkon wrote:
| 3623 total - 1377 upng.c (3rd-party tiny PNG image decoding
| library) = 2246
| charles_f wrote:
| game.c is 800 odd lines. There are some optimizations you
| could do here and there (e.g load digit sprites in an array
| to avoid the switch case 1/2/3... stuff).
|
| The bulk of the 3000 is fluff that you need because this is C
| on Android, not SFML.
| londons_explore wrote:
| A shame that 4k loc compiles to over 100k of binary size.
| kvemkon wrote:
| actually including both architectures: armeabi-v7a +
| arm64-v8a
|
| to check:
|
| - dependencies statically compiled-in
|
| - debug symbols
| lern_too_spel wrote:
| It doesn't. The total APK size is less than 100k, including
| images and sounds.
| mdp2021 wrote:
| It compiles to 37kb of 32bit code and to 48kb of 64bit code.
| /lib/arm64-v8a/libflappybird.so 48kb
| /lib/armeabi-v7a/libflappybird.so 37kb assets:
| 29kb icon: 3kb signature: 12kb
|
| Plus the manifest (2kb) and resources.arsc (0.5kb)
| tropicalfruit wrote:
| i realised recently, there is a correlation between the file size
| of a game and how likely i am to enjoy it.
|
| the smaller the file size the more likely i am to enjoy it. and
| the opposite is true.
|
| i think part of it is time investment. having less time. i dont
| see much value in 60gb of 4k graphics textures.
|
| pac man on the atari or snes is maybe less than 100kb, while
| modern pac man could be easily 10gb or more. same for tetris or
| any game with the same gameplay that hasn't changed much.
| coumbaya wrote:
| You'll love Desert Golfing then.
| nubinetwork wrote:
| NESert golfing is better...
| imp0cat wrote:
| Ninja golf...
| animuchan wrote:
| I totally support this!
|
| Coincidentally I wrote a small 2048-inspired game just
| recently, it's under 13 KiB (zipped; the "real" file is about
| 30 KiB): https://js13kgames.com/2024/games/king-thirteen
|
| If you're interested to check it out, please tell me what you
| think :)
| bubblesnort wrote:
| The game I like most is a multiplayer immersive reality game in
| 0 bytes called frogger, where I'm the frog.
|
| Beat that! ;)
| msephton wrote:
| I got a GOTY 2023 for my game YOYOZO which is just 39KB and
| includes custom physics, online high scores, two music tracks,
| and more. https://news.ycombinator.com/item?id=38372936
| graynk wrote:
| Animal Well is 33 MB and is absolutely great
| mdp2021 wrote:
| Could this technique, using rawdrawandroid to write C
| applications for Android, also use raylib (and other C
| frameworks)?
|
| And maybe could this developing system be used through Termux, to
| have a C development environment on Android for Android?
| deniska wrote:
| Yes, raylib does support android. I have a slightly incomplete
| build script I use for my raylib projects (obviously you need
| to take better care of signing, you probably want to build for
| other targets besides aarch64, your SDK is probably not
| installed in /home/denis, and I'm not sure whether I'm adding
| .so files to apk in a way modern android prefers, but it still
| works).
|
| https://gist.github.com/deniska/f1ee73e18e1444eb724c01f933b6...
| akirk wrote:
| Great work! Good to see what only it takes to run on Android! On
| the other hand it also shows how much comes "for free" or made
| easier by using the provided sdks. For example volume control
| doesn't work while running this. Also resuming the game after
| switching away. Maybe that's relatively easy to save and restore
| state, though.
| sureglymop wrote:
| That's amazing! I wish there was something like rawdrawandroid
| for Rust.
| ladyanita22 wrote:
| Same, would like to see the same but implemented in Rust
| userbinator wrote:
| "For Android" implies Java is usable, and bytecode can be very
| dense, so IMHO this could be even smaller.
| MaxBarraclough wrote:
| There's a Flappy Bird clone for the GameBoy, in the form of a
| 32kB ROM. [0][1][2]
|
| This isn't to downplay this Android-based project though. They
| aren't claiming to have written the most compact Flappy Bird
| clone.
|
| [0] https://laroldsjubilantjunkyard.itch.io/flappy-bird-
| gameboy/...
|
| [1] https://laroldsjubilantjunkyard.itch.io/flappy-bird-gameboy
|
| [2] https://www.youtube.com/watch?v=m839Vg_qXzM
| im3w1l wrote:
| I'm honestly surprised at the 100k figure. In my mind it should
| be possible go far lower. 10k sounds vaguely realistic.
| londons_explore wrote:
| if you're willing to compromise on the graphics and just get
| the core gameplay, I reckon you could do it in a 512 byte x86
| bootsector.
| im3w1l wrote:
| Right. I meant with the graphics though.
| Lerc wrote:
| Weirdly, I think the challenge would be more difficult
| going to Android than adding graphics while keeping the
| size down.
|
| It would not at all surprise me to see a near perfect
| Flappy Bird under 4k (graphics and all) as a PC .com
|
| I'd be curious to see what the minimum size of a simple C
| program would be. Say something that displayed a pixel
| that bounced up and down as you tapped.
| lifthrasiir wrote:
| I think it can be optimized quite a lot by _not_ using a
| stock PNG decoder library, because all images are quite
| simple and can be generated from non-pixelated smaller
| sprites (many images are pre-scaled by 2x, which can be
| done during the postprocessing) or from a simple
| algorithmic code.
| Frenchgeek wrote:
| https://github.com/nanochess/fbird
| melvinroest wrote:
| Tangentially related, I once wrote a literature review on why
| people play Flappy Bird. I was a graduate student in game studies
| at the time. Ultimately, I never pursued the academic route, just
| sharing it for fun.
|
| For the curious minds, here it is [1].
|
| [1] http://www.fdg2015.org/papers/fdg2015_paper_60.pdf
| mctt wrote:
| "It is surmised that conditioning is enforced via several
| cogni- tive biases that trick a player into expecting euphoria
| (liking- pathway), when instead frustration is yielded - with
| condi- tioning being iterated to a point that the player is
| motivated to interact with the game on a foremost instinctual
| level. We posit that these stimulations of the wanting-pathway
| may lead to players interacting with the game not only with-
| out actually liking it, but also without knowing why they are
| interacting with the game. Indeed, this calls for drawing
| another parallel between drug addiction, and play behaviour in
| which liking may be barely exhibited (cf. [16, 38, 40])."
| ddev0 wrote:
| I have always felt there is something fascinating going on
| behind Flappy Birds' infamous difficulty curve that warrants
| deeper study.
|
| On the one hand, there is no actual progression or ramping of
| difficulty in the game itself. The difficulty level remains the
| same whether your current score is 0 or 10 or 100. But every
| new highscore represents a new summit that the player has to
| scale. The first and maybe the most frustrating summit to scale
| is scoring a single point. To get your score into the double
| digits, the player has to have basic mastery of the core
| mechanics - including the precise physics, and timings- and
| learn how to handle a certain number of scenarios. The
| obstacles on the path to triple-digit territory and beyond seem
| almost self-imposed. The fear and tension as you approach your
| own highscore is the biggest impediment to breaking your
| highscore. Once you break that highscore - the hand tremors
| magically disappear the next time you approach it, only for it
| to re-appear as you near your new highscore.
|
| All this, when the basic concept of the gameplay is deceptively
| simple. Like i said, there are many layers to unpack for
| someone who is willing to look into it.
| code_duck wrote:
| Many early 80s 8-bit console games worked this way. I'm
| thinking of games like Transbot for the Sega Master System.
| There are a few different levels, with various enemy
| configurations and scenery, but it has no ending and goes on
| forever without any real changes.
| lencastre wrote:
| Asking for a friend, are flappy bird's levels always the
| same, or are the pipe heights/opening sizes random?
| al_borland wrote:
| If I remember correctly, it was random.
| core_dumped wrote:
| The openings were identically sized, but their position
| was randomized.
| vunderba wrote:
| Look at almost _ANY_ arcade game of the 70s /80s. Most of
| them weren't designed with an end in mind. You play as long
| as you can for the accolades that come with posting your
| initials on the scoreboard.
|
| Asteroids is a quintessential example - relatively flat
| difficulty curve once you've mastered the game - it really
| comes down to a test of the player's endurance. Scott Safran
| set a record game that lasted a grueling 60 hours.
|
| https://en.wikipedia.org/wiki/Scott_Safran
|
| EDIT: Anyone who has _EVER_ tried for a high score (whether a
| personal best, or a world record) is familiar with the
| natural nervousness that increases in direct proportion to
| how close you are to breaking it. That 's not a Flappy Bird
| thing, that's a literal every game thing. Go watch a live
| stream of a speed runner that's got a heart rate monitor
| attached to the feed for example.
| spike021 wrote:
| This was the case for me with Flappy Bird and also that old
| Temple Run game circa 2011-ish.
|
| It's almost more of a game of focus or how much you will
| _think_, because once you're distracted a bit and forget
| those physics or timing just one time, you're probably done.
| johnisgood wrote:
| Thank you for sharing, great work!
| p0w3n3d wrote:
| As an expert in Flappy Bird I Will tell it's because people
| love to approximate polynomials...
| samatman wrote:
| Given that background, the odds you've never seen this are
| exceedingly low.
|
| Nonetheless, and for the benefit of the Lucky 10,000, I must
| present: QWOP.
|
| https://www.foddy.net/Athletics.html
| nubinetwork wrote:
| So this is an android apk, and not a Linux app that just happens
| to run on android? I'd really be curious as to why most android
| apps are huge...
| freitzzz wrote:
| Most Android apps are huge because they bundle tons of assets
| just to accommodate the "initial experience of the user". Also,
| using bloat libraries and frameworks (any shipped by Google),
| increase the apk size.
|
| Nowadays Google offers a solution for this problem called app
| bundling. It's especially good if you build a mono app that
| behaves differently in certain regions. Instead of delivering a
| raw apk, you deliver a region specific app bundle.
| londons_explore wrote:
| I'm unaware of any apps that behave totally differently in
| different regions.
|
| Sure - there are sometimes a few disabled features in one
| region or another, but is that really worth shipping a
| totally different binary for?
|
| Even language packs can be tiny even for 200+ languages if
| they're pure text.
|
| It's only when you get language/region specific artwork that
| there's a problem.
| freitzzz wrote:
| You'd be surprised how heavy a language pack is!
| immibis wrote:
| I made a sub-100k Android app once (I am now banned from the
| Play Store, and I should be lucky they didn't delete my Gmail
| account too) and every time I opened the IDE (Android Studio at
| the time) it would automatically add a Google "support library"
| to the project that Google obviously wanted to force me to use.
| If I forgot to remove it and built the app, it would be closer
| to 10MB. So that was the minimum size of almost every Android
| app at the time.
| laweijfmvo wrote:
| isn't this kind of what Flutter is? a (relatively big) framework
| to just draw frames to a barebones Android app.
| seabass-labrax wrote:
| On a technicality, yes, but I think most developers who use it
| do so because of the large collection of React-style user
| interface components which are built into it. Now that Jetpack
| Compose exists (which allows for traditional Java-based widgets
| to be used in a 'reactive' way), personally I don't see any
| reason to use Flutter. That 'drawing directly' aspect puts
| Flutter apps several years behind in terms of performance,
| accessibility and reliability, since pretty much everything in
| the Android API needs to be reimplemented in Dart.
| londons_explore wrote:
| Really wish the app store had a "only apps under 10MB" filter.
|
| The fastest, least ad-filled and micropayment filled apps are
| usually the small ones. By downloading a 3 megabyte thermometer
| app you'll be much happier than a 150 megabyte thermometer app.
| onlyforthat wrote:
| I remember there was a publisher in Play Store who had very
| small apps like single digit kb flashlight, sudoku, calender,
| etc. I can't find them now. Those apps were really small all
| within <200kb
| butz wrote:
| Google Play probably kicked them off for not using latest
| Android SDK or something. So many tiny and high quality apps
| were lost.
| johnisgood wrote:
| Google is not only killing their own projects, but other
| people's, too.
| refulgentis wrote:
| I'm no fan of Google, but it's slightly more complicated
| than that, there's a lot of security and privacy stuff
| that can't be enforced if your app was build 6 years ago
| and still slopping around.
| tourmalinetaco wrote:
| Does that really matter for a local-only 5KB app that
| only talks with my phone's flashlight, or reads sensor
| data? Now, maybe for the 500MB adware-filled "flashlight"
| app that connects to 100s of servers and demands access
| to everything my device can do, but that would be banned
| on any competent app store anyway.
| ninetyninenine wrote:
| No but enforcing policy is manageable. Enforcing
| reasonable security measures based on nuances and case by
| case situations is not manageable for an ecosystem of
| that scale.
| JoshTriplett wrote:
| I don't know if this is still the case, but at one point
| the permission needed to access the flashlight also gave
| access to the camera. And there _aren 't_ restrictions on
| network connections from apps. (I'd love to have app
| network access restricted by permissions, but that would
| be a large change.)
|
| And in any case, Android has had built-in flashlight
| support for a while now, for any phone that has a camera
| with a flash. Is the "turn the screen bright white" style
| still useful with modern Android?
| MrLeap wrote:
| It is if your flashlight's broke.
| epmaybe wrote:
| This is something that really bothered me - I had an app
| that was small and worked fine on the latest Android OS,
| yet they took the app and account down because we hadn't
| uploaded a new version in a year. Appeals didn't help
| heyoni wrote:
| What was their reasoning?
| jart wrote:
| To keep you running on the hamster wheel.
|
| They'd ban Mozart and Shakespeare from the app store if
| they could.
| bee_rider wrote:
| I don't think that was their reasoning.
|
| Like, Google, all these megacorps, they are bad, but we
| should at least argue against their actual arguments.
| jart wrote:
| I didn't know you participate in the tech community to be
| a subversive. Here's a little tip.
|
| When you focus on their arguments, you're playing their
| game.
| ryandrake wrote:
| 3P app developers are also complicit. Often they
| deliberately cut off support for old OS's and old
| devices, because it's "too hard" to support them or
| whatever. Everyone seems to be working together to keep
| us on the hamster wheel.
| PhasmaFelis wrote:
| There may not have been any. Individual app-store
| reviewers can block you any time they feel like it, the
| guy checking your appeal is the same, and none of them
| have any real pressure to behave unless you have money
| and corporate power behind you.
| azthecx wrote:
| I use the minesweeper, sudoku and solitaire apps from
| dustland design (search pub:Dustland Design) they're very
| minimalistic and clean.
|
| There's also currency / unit converter and calendar by Sam
| Ruston which are in the same vein very good and clean.
| bongobingo1 wrote:
| https://play.google.com/store/apps/developer?id=Dustland+De
| s...
|
| Nice!
| bcraven wrote:
| https://simplemobiletools.com/index.html
|
| The gallery app is superb.
| lambda wrote:
| Weird that their GitHub says "without ads", but the apps in
| the play store say contains ads. It looks like they're
| doing ads/paid model in the app store, are they ad-free
| from F-Droid?
| zwirbl wrote:
| It was sold to an adware vendor that is milking the brand
| hard. Another one for the 'used to be great' pile
| aorth wrote:
| The Simple Mobile Tools suite was sold to an adware vendor
| last year. Plenty of links to stories if you're interested,
| even here on HN.
| p4bl0 wrote:
| Yes, the SMT apps are slowly being forked over to the
| Fossify project: https://www.fossify.org/.
| Viliam1234 wrote:
| I can't even get angry at that, because it seems like
| just another popular business pattern:
|
| * build a nice product
|
| * become popular and gain trust with customers
|
| * sell the company to a scammer
|
| * profit!
| valval wrote:
| I'd do that in a heartbeat. I have a family to take care
| of. My customers can follow me to my next project.
| JoshTriplett wrote:
| > I'd do that in a heartbeat.
|
| > My customers can follow me to my next project.
|
| If you are willing to sell your customers to an ad firm,
| why should they trust your next project?
| Sarkie wrote:
| https://play.google.com/store/apps/dev?id=821434617619498026.
| ..
| sprak wrote:
| This (Simple Mobile Tools) used to be a good set of apps.
| But it got bought up a an ad firm. The new, still ad free
| apps, are known as Fossify: https://play.google.com/store/a
| pps/dev?id=729783837865432255...
| bscphil wrote:
| I'm surprised to hear this. Fortunately it doesn't look
| like the source code itself got taken over [1], and of
| course F-Droid, which is always the best place to get any
| open source Android application, still has the same
| version as the latest Github release. [2]
|
| These applications are blessedly feature complete, and I
| haven't noticed any issues being "stuck" on the F-Droid
| versions.
|
| [1] https://github.com/SimpleMobileTools/Simple-File-
| Manager
|
| [2] https://f-droid.org/en/packages/com.simplemobiletools
| .filema...
| Sarkie wrote:
| Ah yeah.
|
| Forgot about that!
| simonmales wrote:
| f-droid is a great way to find bloat free apps
| Vt71fcAqt7 wrote:
| How would this feature handle an update that increases the file
| size? What about apps that download assets after you install
| them?
| Ylpertnodi wrote:
| Isnt this one of the world's software ...why would a
| thermometer (for example) app need updating? And, would you
| let it?
| oneplane wrote:
| Because a thermometer is software and software is
| imperfect. Perhaps it made some assumptions that causes
| phones that were released after the app was released to
| drain the battery very quickly. Or it has a calculation
| error where over time it accumulates a significant
| difference between the measurement data and the data that
| is rendered on screen. Or perhaps it's using an API that we
| all thought was safe, but turns out it's not. Or it needs
| to use an API to get temperature data (thermometer can have
| different meanings) and the API no longer exists.
|
| Even something as silly as an app that does nothing can run
| into these issues. The APIs and other interfaces used to
| run applications are imperfect. Sometimes doing nothing
| about it is a choice, sometimes the vendor doesn't deem
| that acceptable and then it is no longer a choice. Either
| way, the application will have to adapt or degrade (to the
| point where it degrades out of existence).
| yieldcrv wrote:
| That reminds me of one reason I got out of mobile app
| development, totally forgot about until now
|
| Often times the hiring managers wanted to see something more
| akin to a portfolio, like an art project, for apps that many
| times didn't exist anymore or have a production server up
| anymore
|
| But the more arbitrary metric was trying to be sure that I
| worked on anything "big"
|
| And the 8-12 megabyte package sizes - which I spent a lot of
| time optimizing with many competence inspiring techniques -
| would signal that the app or service or userbase wasn't big.
| Which had nothing to do with anything, could have hundreds of
| millions of downloads and users
|
| In that space there is a _huuuge_ incentive for bloatware
| sunnybeetroot wrote:
| I have never experienced nor heard of a hiring manager
| determining the outcome of a candidate based on the MB of an
| app they worked on. I would run away from working for a
| company like that.
| nixass wrote:
| Why, what's wrong with 172MB calculator app?
| bagels wrote:
| Whatever is in the extra 150MB. Ads, spyware, bloat, slow
| performance.
| kragen wrote:
| i would say 'whatever is in the extra 171.97 megabytes'
|
| i wrote a calculator app including its own implementation
| of decimal floating point and it's still only 20 kilobytes
| internetter wrote:
| 1. I doubt this includes GUI
|
| 2. The Qalculate CLI is 2mb, so perhaps your 20kb
| calculator could add some features while still being a
| 100% pure calculator
| kragen wrote:
| yeah, the 20-kilobyte calculator runs as an x-windows
| application, but it doesn't have any buttons or anything;
| it's keyboard-driven. the 'gui' is https://gitlab.com/kra
| gen/bubbleos/blob/master/yeso/yesocalc...
| oneplane wrote:
| A calculator app doesn't need that many megabytes of code and
| assets to be a calculator app. So if an app is way bigger
| than it should be, it usually means one of two things
| (usually!):
|
| 1. The app was not very optimised, perhaps created by a
| novice, containing a lot of things it doesn't need.
|
| 2. The app used to be really small, but a lot of extra code
| was added to serve you ads, profile you for better targeting
| or do sneaky stuff you didn't ask for.
| mdp2021 wrote:
| If a trip to the baker took 172 days, there would be over 171
| used days to justify; if it took 172 engineers to change a
| lightbulb, it would have to be a very special lightbulb or
| explanations should be in order. Besides uses of concern of
| the extra resources spent, it simply just makes no sense.
| nixass wrote:
| People here are vaccinated against sarcasm it seems
| mdp2021 wrote:
| People arrived to this shore after having experienced that
| what they considered unbelievable and untenable is actually
| believed and held by some - who may not even seem to be
| particularly an uncommon tail of an emerging population.
|
| And this is why a good '/S' keeps you safe from
| misunderstanding.
| camel-cdr wrote:
| Nothing, but it better have a fully featured computer algebra
| system baked in.
| userbinator wrote:
| Early versions of Mathematica were only a few dozen MB and
| certainly have more functionality than probably most
| calculator apps you can find that are much bigger.
| nuancebydefault wrote:
| I would add an /i to keep your karma happy
| Waterluvian wrote:
| The red flag for me is that they're all "free."
|
| Let me filter by apps that cost money, are ad free, and
| sometimes even: don't have in-app purchases.
| n_plus_1_acc wrote:
| Aurora Store can at least filter by paid/IAP/has ads
| refulgentis wrote:
| I continue to be puzzled by how much smaller apps are on
| Android, ex. Took me 9 tries, including ads, to find a
| thermometer app over 7 MB. I've worked on both platforms for
| years and yet don't really know why. Only guess is Android has
| a much richer tradition of vector art over bitmaps, and Swift
| libraries had to be compiled in for years until ABI stability
| enabled using dynamic linking to OS ones
| Ciph wrote:
| Doesn't fstore have a filter for that?
| jart wrote:
| > 150 megabyte thermometer app
|
| Does such a thing really exist? Or are you just making a point?
| robbiewxyz wrote:
| This reminds me of code golf, an activity I had some good fun
| with as a young teen.
|
| Coincidentally, one of my first contributions to the community
| was a low fidelity "flappy bird" clone in less than 0.5 kb of
| javascript. Maybe someone will find fascination in my old hobby
| and its surrounding community:
|
| https://codegolf.stackexchange.com/a/23452
| lifthrasiir wrote:
| Do you still accept more optimizations? :-) I believe there are
| tons of _mechanical_ substitutions that can be made there, for
| example `i%17?r+=z:r+= '|\n|'+z` should simplify into
| `r+=i%17?z:'|\n|'+z`.
| forgotpwd16 wrote:
| If constrained by size of result rather source you get
| sizecoding, a generalization of demoscene.
| huem0n wrote:
| Nice codebase . That's some if the best looking C I've seen in a
| while.
| tiffanyh wrote:
| Super Mario Bros was just 40KB
|
| https://news.ycombinator.com/item?id=21213421
| mouse_ wrote:
| It was also made to work on exactly one hardware specification,
| with no operating system to speak of. This flappy bird clone
| works on an immeasurable number of devices, with varying
| hardware AND software configurations!
| tiffanyh wrote:
| Cosmo gives you what you described above and it's <10kb
|
| https://github.com/jart/cosmopolitan
| jart wrote:
| Well these days cosmocc -mtiny is more like 120kb, now that
| our binaries support ARM platforms too (like Android!) and
| all the code I've needed to add to make sure Cosmo works
| reliably for a longer tail of edge cases. But that's saying
| a lot, since unlike these APKs cosmo binaries don't need a
| gigabyte JDK to run.
| cies wrote:
| Interesting to see what a Windows-based project looks like. I
| haven't used Windows for ages. Seeing the .bat files and vsproj
| files gave me nostalgic feelings.
| p0w3n3d wrote:
| Too fast on my Samsung A52s
| psanchez wrote:
| I was under de impression java gluing was required to create
| Android APKs. Really nice to see this project. 0 java files.
| Bravo.
|
| Also worth looking at the rawandroid project like others noted:
| https://github.com/cnlohr/rawdrawandroid/tree/master
| klibertp wrote:
| The reason you have Java glue instead of C glue in most cases
| is that Java's is easier to write. Whatever you do, you need a
| Activity instance to run, and while you _can_ create one from
| C, it requires a lot of boilerplate that is mostly taken care
| of by inheritance in Java. Here 's how it's done in plain C:
| https://github.com/VadimBoev/FlappyBird/blob/master/FlappyBi...
| https://github.com/VadimBoev/FlappyBird/blob/master/FlappyBi...
| pjmlp wrote:
| Also even the "pure" C one depends on Java, because
| Activities exist only on the Java side of Android.
|
| In practice to be usable on a standard Android system, native
| code must always be compiled to a shared object, with JNI
| entry points to be called from Java userspace.
|
| The only option is to write such native methods ourselves, or
| use one of the two predefined Activities for NDK that already
| expect specific functions to be present on the shared
| library.
|
| Additionally, the zero Java part only works, if what NDK
| exposes as stable API is enough, and from Google's point of
| view, that is only for games, or faster compute, everything
| else requires JNI fun.
|
| As tip, it is easier to deal with Android IPC for Java <->
| NDK communication, than going through JNI boilerplate.
| mouse_ wrote:
| Couldn't one simply make the boilerplate once, as a library,
| that takes the pertinent bits as arguments? In which case if
| your app is C anyways it would make sense to just keep it
| simple with that.
| infomiho wrote:
| Missed opportunity: name it Floppy Bird since it fits on a 3.5
| inch floppy disk.
| kragen wrote:
| here in argentina everyone calls it 'floppy beard'. and of
| course 'angry birds' is 'ongry beards'
| userbinator wrote:
| That came to mind for me too, but unfortunately the name has
| already been taken by a few clones; the most notable being a
| trivial reskin that uses a floppy disk icon instead of a bird.
| dielll wrote:
| Add it to Fdroid
| charles_f wrote:
| This is impressive, especially that it's fully in C.
|
| I'm wondering, can you debug C apps on Android?
| mdp2021 wrote:
| Possibly through Termux... Surely for shell commands, I would
| say; I am not sure about hooking the debugger to a package
| jaakl wrote:
| Why so many bytes? I wrote one using just 141 bytes and it took
| just few seconds to write, and it is the first functional game
| I've ever written). Result:
| https://claude.site/artifacts/3b35069f-4d51-4415-9f58-69988c...
| kragen wrote:
| nice! but how big is the .apk?
| squeaky-clean wrote:
| I'm not sure if this is a joke or not, but there's no actual
| graphics in this besides a yellow ball and green rectangles,
| while the OP game has actual textured pipes, a textured floor,
| a background scene. The score counter looks to use a basic
| system or browser font, while the OP game has a custom font.
| The OP game has also high score tracking, sharing, a proper
| main screen instead of just dropping you into gameplay.
| justmarc wrote:
| It is refreshing, and nice to see programs/games/apps that are
| "crafted" vs just slapped together out of existing, bloated third
| party components.
| akavel wrote:
| I did something similar in Nim and published it in 2020 (less
| pretty graphics however). The difference is that I went deeper
| and actually wrote an assembler for the Dalvik bytecode and .apk
| files:
|
| https://www.youtube.com/watch?v=wr9X5NCwPlI&list=PLxLdEZg8DR...
|
| The code in the repo has unfortunately bitrotten. I am sometimes
| thinking to try and resurrect it Some Day(tm)... from time to
| time I think of some simple app I could write if it was a bit
| more polished.
| saturn5k wrote:
| You should check out .kkrieger an fps game in 96kb. A relic from
| the demoscene.
___________________________________________________________________
(page generated 2024-09-22 23:00 UTC)