dueal:

If I get you correctly, your assumption is you can make a 2d skeleton system with just images(jpg,png) and that's cheaper than using vector-graphics techniques which you assume will be more computationally expensive? It's actually the opposite.
Let me explain. The thing your gpu api(opengl/d3d) processes first are vertices(points) not bitmaps, bitmap images get painted on polygons. So, using vector-graphics techniques which are lines defined by points is a natural thing for d gpu. These are scalable with less aliasing effect than scaling a texture images, they are controllable with joints/matrix-pallets than trying to figure the boundary of a bitmap character and rewriting the new image/snapshot of animation as another texture. Computationally it's cheaper cos you are working with less data(vertices vs texels).

I know you know graphics pipeline. I do too. I know the benefits of vector graphics, but performance is definitely not one of it. Just like you said bitmap images are passed as texture to polygons and that's the end of the story. If you are rendering just an image you do not need more than the 2 triangles that form a quad around the image. For vectors however, its a different story. Graphics APIs only understand 3 base primitives: points, lines and triangles. Vector images contain a lot more than that. They use bezier curves, they allow specifying stroke width, filled color can have varying gradient, etc. Those require conversion into something OpenGL/D3D understands and that is a lot of computation considering you will have a game world composed of these stuffs. And at the end of the day a vector use more tris than a raster image, since the curves and strokes have to be resolved into triangles.
The overhead of conversion is totally not worth it. Vector graphics are mostly used in GUI rendering, logo design, or only for little parts in a game that needs a scalable image.
And texel count is less a problem, since it is handled parallelly by the GPU. But vector to polygon conversion is done on the CPU. And again a vector image use more vertices than a raster image, just as I pointed out above.
I implore you to check this out:
http://programmers.stackexchange.com/questions/191472/why-have-hardware-accelerated-vector-graphics-not-taken-off

idu1:
Whats your company into?

It's in the post na.

Guys a new game dev group is up. If you wanna join.
https:///DnZJjT0VCWAHdG9MTkxiLi

dueal:
Also, if you understand the modern standard graphics pipeline model GPU's follow everything is going to be rasterized at some point.

So when I say vector-graphic I mean techniques similar to what happens in Adobe Flash, with points and filled shapes, tessellated then sent to hardware and rasterized.

But the raster standard u talk of, i'm guessing u mean jpg, png, or something else.

I know what you mean by vector graphics. And yes, the raster images I talk about are jpg, pngs etc., the pixel-based non-scalable images you can pass to OpenGL/DirectX directly. You can't do that with vector graphics. Lots of computations will be done before those points, beziers, fill, stroke, etc. are converted to polygons which are then passed to a graphics API. And that is why I can't consider them now.

KvnqPrezo:

Mehn I must confess that it's the best site that I have seen...

For you, Ok.

Jonart247:

nop, i'm no more interested in game developing anymore

Ok

dhtml18:
For the wailers on the thread, how many features have you suggested to Facebook? and did you guys never read that NAIRALAND IS A PRIVATE FORUM? Bunch of i-dont-even-need-to-say-it.

Should that stop us from suggesting ideas to indigenous creators.

Fedric:
i wonder ooo, wey tin concern them with person business. they should go build theirs.

am currently learning programming. life is too short to take panadol on someone's headache. lol

i have a strong drive to build a great website not to see someone weekness lol

That just doesn't make sense. He is a user, so he can give suggestions. It's up to Seun to either take it or leave it.
I, for one, want NL to add more features, probably changing it's theme or allow user-genrated mods. Any how, I'd like to see nice changes.


PS: You know the definition of insanity. Doing the same thing over again, expecting a different result.

Jonart247:

na ur choice

Created. Will you join?

dueal:
Also, if you understand the modern standard graphics pipeline model GPU's follow everything is going to be rasterized at some point.

So when I say vector-graphic I mean techniques similar to what happens in Adobe Flash, with points and filled shapes, tessellated then sent to hardware and rasterized.

But the raster standard u talk of, i'm guessing u mean jpg, png, or something else.

Obviously.

So... is someone going to create a whatsapp group for gamedevs?
Make I kuku create one.

reggie02:
@appcypher! can I see some of yours?

Just some character I drew to test animations in Crude.

Can we have a Whatsapp Group for game devs?

dueal:



Since your inspiration if from UbiSoft then I hope you know they used vector-graphics and alot of character parts, some general, some action specific. Yes, the programmability of skeletal over sprites is one thing and the memory budget another. But how much memory, and how much programmability?

A pack of sprite frames for one character in a fighting game like street fighter, with combos and power moves cos just a lil above 200KB.

And in most games you don't need all that tracking stuff and fancy programmability. Remember, you don't only deal with memory budget, there is processing and cache management to think about, where on mobile you typically have 65MB+ for you game and lower clocking CPU's.

Yes, 2d skeletal system will be useful where the situation allows, but only where it supersedes sprites in a 2d game.

More knowledge, less search applies to game dev too.

Yeah, UbiArt uses vector graphics, but raster-based images are still the staple in the industry. I will probably consider it in the future, but only when it is really needed.
You do know that street fighter spitesheet pack are low-res images. You can't have HDs of those without consuming megabytes.
Even in spritesheet-based games there could still be elements of skeletal animation like rotating, translating or scaling sprites.

And you said most games don't need tracking stuff or fancy programmability. I call that BS. 2D games are not the way they are before. Retro 2D games that look like Mario or Street Fighter are smaller niches now.
Developers definitely want great programmability over their animations. At least most I've seen do.

I know you like/prefer spritesheets, but you can't just simply close your eyes to the benefits of skeletal animation. From character's hand/gun following the mouse, to blending between animations (running and jumping), to using the same set of animations on different characters. The list is endless. Skeletal animation doesn't limit you to a set of spritesheet, you can have enough animations and your sprites at high resolution. You can't have both with spritesheets.
As for performance, skeletal animations indeed take more oomphs from the CPU, but spritesheets also have memory bottleneck due to the command queue delay between CPU and GPU. But caching is greatly improved with skeletal-based system because you have fewer sprites to deal with.

I for one, plan to create a game that needs a lot of procedural animation going on, that I will never be able to achieve with spritesheets (not unless I go back in time and change the meaning of spritesheet). The game requires smooth interpolation between different animations so that it looks like one continuous animation (think the combat-style Batman Arkham games). I've not seen stuffs like that in 2D games and that's one of the reason I had to create Crude. This combat style also requires the characters to react dynamically to each other's attack. Spritesheet is too rigid for this, I will have to draw out every possible animations, which is impossible.

Anyway, I'd love to see how many dudes prefer spritesheets to skeletal animations.

reggie02:
@kishimi8 oh yeah? that's cool! I'm looking to find some partners as well, which is the purpose of creating this thread.
@Scholar01 true, it's kinda dull but it's mostly because there hasn't been any "hit" game from naija devs so no motivation for others. If we can achieve that, the dulling will stop... I hope..

Welcome to the thread guys! if you know anyone that's good at any aspect of game development, direct them here please! Also, if you have anything to show off, that'll be awesome.
Here's a [non-game dev.] sketch i did some years ago:

Your illustrations are nice. I love the color composition. I draw too

dueal:


Skeleton systems are a lot better for 3D models. If you insist you want a 2d skeleton system then you'll better prepare to use vector-graphics and a lot of different character parts. 2d skeleton isn't as efficient as 2d sprite systems.

Advice.

Reverse is the case actually. Skeletal 2D animations are generally preferrable because of the flexibility it offers. All you need are the parts of the character. For spritesheets, you need more than just that. You need the image of the character for every frame of animation.
So here are some of the reasons why one would prefer Skeleton-based animations to spritesheet:

- Spritesheets take up a lot of memory than skeletal-based animations do. This is usually bad for mobile game dev where memory mgmt is vital.
- Spritesheets require you to draw each frame of animations. This is very tedious. What if you needed several dozens of animation.
- Spritesheet animations cannot be more than the fps they are drawn. If you drew 5 frames for a particular animation, then that is what you get. Skeletal animation can interpolate to whatever fps you chose. You can even do slow motion or fast forward with the same data.
- Spritesheets are not programmable. i.e. you cannot interpolate, mix or change the animations at runtime. For example, you can't make your characters head track the position of a mouse cursor.
- Skeletal based animations allow you to reuse the same animations for different characters. For spritesheets you'd have to redraw such characters animation.
- Because Spritesheet consume a lot of memory, you can't have high-res characters. But with skeletal based sprites you can have relatively high-res characters because you are reusing the same set of sprites every frame instead of new ones like spritesheet does.
- Sprite sheets are rigid, you cannot simply edit/change an animation you've already drawn, you have to redraw another. Skeletal-based allows you to edit your animations, show your client or team and go back and edit if needed. You cant simply do that with spritesheet, there would be a lot of wasted efforts drawing each frame by hand.
- For teams where there are several animators and where the animtor is different from the artist, skeltal animation will make the workflow easy cos animation data is different from sprite and there is only one set of sprites to share.
- And intros and cutscenes (e.g. translation of title bar, flipping page, etc. ) are better done with skeletal animations than spritesheet drawings.

There are many more reasons I can't list here, but you get the gist. I'm definitely not implying that skeletal animations are better in every way than spritesheets. There are definitely use cases for spritesheets, but most of the times skeletal-based animations are preferred.

Another thing. Vector graphics are not really used in game dev due to the way OpenGL works and I probably wont support it.
Raster images are good enough for most cases. And vector graphic rendering are performance killer, so definitely not what you will want to be using too much in your game. I may look into that later though. But it is definitely not on priority list.

There are several 2D skeletal products out there.
- Spine, industry standard, but expensive.
- Spriter, cheaps but lacks some features like FFD/mesh deformation
- Creatures, feature-rich but expensive and complicated.
- Dragon Bones, free but buggy and lacks proper documentation.

This is where mine comes in. It is called Crude and it is free and open-source. It will sure cover a lot of important features.

The development of Crude is inspired by UbiArt the engine used to develop Rayman Legends and Rayman Jungle.

reggie02:
Hi all. While lurking around the forums, I noticed the lack of a topic where [aspiring] video game developers interact with each other. I feel this is important to further promote the indie game dev. scene in naija. I found none though... so if there is one, can a kind person direct me towards it? If not, let this be it then
I'm a strong believer in the video game dev. potential of naija, so I'd love to be able to communicate with others like me so we can motivate each other, critique our works or maybe work on something together
SO if you feel you're a dope artist, 2D/3D animator, programmer (with unity, game maker, unreal, etc), designer or sound person, come link up at this game developers' post! (if there isn't one already that is).
Here's a sample of what I can do. Thanks guys
-reggie02

Cool! One of the few.
I'm good with Unity and I'm currently working on a 2D skeletal animation software.
I like your character, is it spritesheet-based or skeleton-based.

You also need to join the numerous whatsapp groups advertised here. You can inform the group members about your site.

Booyakasha:
But the whole idea is farfetched, why do you think people will leave Facebook or Twitter to use your tytit (it's a really cool brand name)?

I don't think people leave one social network for another, they just create accounts and visit each one. So the real question should be how likely are they to come back and how will the app get its audience. For me, I was attracted by the simplicity of the design and I believe it will go far with the right marketing.

Please allow edit feature. I don make my first grammatical blunder on your platform.
And follow me too.

appcypher:
I signed up, but I'm unable to log in. Username is AppCypher.
I like what you are doing here. Hope to see more.

Resolved!

[s]I signed up, but I'm unable to log in. Username is AppCypher.
I like what you are doing here. Hope to see more.[/s]

KvnqPrezo:
I Hope Am Making Sense.." All Programmer Must Know How To Create Template..before learning Any Language....**Somebody Should Quote Me Wrong...

No they musn't. Not all devs are web devs.

onakevin:
10 - CUDA

Most people take the power of their video cards for granted. They don't even think about how many triangles the video card is juggling, as long as their world is a complex, first-person shooter game. But if they would only look under the hood, they would find a great deal of power ready to be unlocked by the right programmer. The CUDA language is a way for Nvidia to open up the power of their graphics processing units (GPUs) to work in ways other than killing zombies or robots.

70% of the list is not new

My own is as long as the pay fits the requirements, no problemo.
I do think specialization matters tho. Makes work faster and efficient.

App Dev
appcypher@gmail.com
08108753144

Building an Android app comes down to two major skills: Java and Android. Java is the offical language of Android development, but it also encompasses learning XML for the design of the app, learning the concepts of Android, and using the concepts programmatically with Java.

Once you learn Java and XML (XML is really easy to get used to, and you should learn the language as you program your app rather than learning it beforehand like you would with Java), you need to learn how to connect these two using Android principles.

For a total beginner, I recommend learning Java. There are no shortcuts here, you just have to learn Java.
You can start with YouTube tutorials to get the basic idea of how to install Eclipse (the Integrated Development Environment, or IDE, for Java) and the Java Development Kit (JDK). It also helps to get the basic idea of syntax behind Java concepts, such as for loops and if statements.

But from then on, after you have learned the very basics, I highly recommend ditching the YouTube tutorials in favor of a book or a lecture series. YouTube tutorials very often do not give intuition behind important concepts, which I feel is 100% necessary if you wish to make an Android app.

Using Google to search up any questions that you are stuck on will save a lot of time and stress. The top results will usually lead to Stack Overflow, but when Stack Overflow doesn't have an answer you can post your questions on /r/androiddev Subreddit. They are always there to help.

So to wrap it up, here are the 5 basic things you need:
1. You need to learn Java, there is no way around it
2. Android part encompasses learning XML for the app design, understanding concepts of Android and using said concepts programmatically with Java
3. Beginners should probably use an IDE (I prefer Android Studio over Eclipse)
4. Building your first app is time-consuming: it won’t happen overnight. This is not a project for those looking for a fast result
5. When stuck on a problem (which will inevitably happen), turn to Stack Overflow. If no luck there, seek the Android Subreddit where there is a helpful community

- learntocodewith.me

PS: For your front-end or back-end Windows, Android, Linux and Mac app development, you can contact me at:
appcypher@outlook.com
08108753144
My services are cheap.

Flying my ass. Wizard my ass. The dude probably has some mental disorder.