chao51 said:
I am into retro games, so I am 0% interested in most modern gaming features.

“Modern” is a term like AAA, it isn't describing the engine itself, this code hasn't changed or has barely changed since Unreal Engine 1 in it's overall look and feel. You need math like you needed math in 1980, what has changed is the amount of memory you can address and the speed as same as some threading, but all of that was already there in the end of the 90s. So what do you consider “Modern” in a game engine?

I don't believe you're pushing every pixel to the screen all at your own, I guess you're using OpenGL e.g. WebGL or at least some “modern” draw features (compared to 1980).

Modern in case of game engines is mostly a term used for the production features and you can never have enougth production convenience today

Hi @Shaarigan !

Shaarigan said:

chao51 said:
I am into retro games, so I am 0% interested in most modern gaming features.

“Modern” is a term like AAA, it isn't describing the engine itself, this code hasn't changed or has barely changed since Unreal Engine 1 in it's overall look and feel. You need math like you needed math in 1980, what has changed is the amount of memory you can address and the speed as same as some threading, but all of that was already there in the end of the 90s. So what do you consider “Modern” in a game engine?

I don't believe you're pushing every pixel to the screen all at your own, I guess you're using OpenGL e.g. WebGL or at least some “modern” draw features (compared to 1980).

Modern in case of game engines is mostly a term used for the production features and you can never have enougth production convenience today

Moderns is of course a relative term, I agree. For me retro (==really old) vs Modern is more or less the list below:

-2d pixels vs 3d objects / voxels / ..
-simple NPC behaviour / Complex NPC behaviour, with a flavour of AI
-Local only / Networking features (multiplayer, score saving, chatting, in-game voice call, etc)
-content size: 1 man can do it all / we need a complete team to do it.


Regarding the pixel pushing, I am neither using OpenGL or WebGL, but the browser Canvas API. Not much pixel pushing indeed.

Cheers
/C51

There are a few misunderstandings between you and @shaarigan , one of them being that you try to describe games you like making (even with modern tools) while it seems you also turn down “modern” tools to accomplish this, despite you using the modern tools. It's just a minor misunderstanding.

This however:

chao51 said:

For me retro (==really old) vs Modern is more or less the list below:
…
1 man can do it all / we need a complete team to do it.

Is not correct IMO; never has it been easier to make a game as a single individual.
In the same manner, plenty of games in the 80s have been made by a sizable team.

The methods available to us today is what makes it much easier to make something single-handedly.
Of course the big productions typically have lots of people working on them, but it was always so.

Hi guys,

I am not trying to pick an argument, I am just trying to clarify that the engine I was showing is just for fun, and super simple, and doing things in ways that you may or not agree with.

Why?
Just so no one digs into it deeply, and gets out on the other end dissapointed. So all I am trying to do is make that super clear.

In general, I have nothing against “modern” features. And I know my list of what is modern is nor complete nor super accurate.
Also I like and use modern tools, and I do play modern games from time to time.
But not this particular project.. Thats all ?

Cheers
-C51

chao51 said:
In general, I have nothing against “modern” features. And I know my list of what is modern is nor complete nor super accurate.

Then simply forget about your list, you're doing a retro game engine and that's it ¯\_(ツ)_/¯

AI btw. was also really complex in Warcraft and Starcarft already so this isn't an argument too! Because I can remember to have played Starcraft in the 90's and we had a copy of Warcraft II at home ?

chao51 said:
Just so no one digs into it deeply, and gets out on the other end dissapointed. So all I am trying to do is make that super clear

You need to count on someone digging into it for sure if you're posting into an engine discussion. If you're not confident with your work, well don't show it. No one will blame you for doing what you're doing except if you're saying you made a game engine and just put some third-party libraries together, then be aware to be blamed by me!

But you already mentioned to do everything on your own so what

I am currently on the same "lane" as you.

My approach or “mental map” is different, though. I am a fundamentals first person. So these are my pointers that I think will help you to get to your goal:

Rendering algorithms for creating the rendering sub-engine:

- Bresenham's line drawing algorithm (needed for rasterization; wireframes; lines)
- Triangle filling algorithms: Pineda's algorithm (edge functions); good and simple alternative to scanline raserization
- (Primary) ray tracing (an alternative to rasterization; no projection matrices needed; you deal mostly with intersection tests)
- Matrix transformations: perspective projection, camera
- Viewport transform (image plane inside the world space - a coordinate system - to the monitor coordinate system - raster space)
- Painter's algorithm vs z-buffering (choose one of them; Painter's algorithm is simpler and less memory intensive)
- Phong shading (expensive), Gouraud shading, flat shading (simple)
- Texture mapping

For the main system:
- game loops: fixed vs variable timestep (how to reach frame rate independence for your physics code?)
- LERP - linear interpolation (smooth movements)
- framerate capping; how to cap your framerate in a game loop (avoid sleeping; don't use SDL_Delay() or something)
- OBJ (3D model) file handling (import and export)

I would start with a simple rendering pipeline. Take the PlayStation 1 for orientation. The rendering loop might be something like this:

for each triangle in triangles:

for pixel in pixels:

if (pixel is inside triangle)
color(r, g, b, a)

The rendering stages (or pipeline) goes like this:

0. Transform
1. Project
2. Z divide or perspective divide
3. Viewport transform (from the projection plane inside your world space to your device's coordinate system - raster space)
4. Fill

This is a very simple/basic rendering pipeline. Do this first, before adding more complex stages.

About sound and other systems. I am not so experienced in that, and I currently don't have any useful pointers for it.