Comparing Game Tech/Gfx

[S0ulA55a551n]

Thought I would create a new thread as I had accidentally taken over the robocop thread Mods feel free to move the OT posts from there to here.

I will admit I am not game programmer, or certainly not to any high level or on the Amiga so do not know the intricacies of the craft. I know a lot of people here are so hoping to learn.

To my mind, the engine and the graphical output ( but not style) are connected.

I do not know the specs of the Robocop arcade game, but I am going to guess its higher resolution and considerably more colours on screen than robocop 2 on the Amiga.

To me the engine has to support the res, size of sprites, colours etc.

Hence no way is robocop 2 a better engine that Robocop arcade. No matter ones, views on the graphical style ?

Discuss

[gimbal]

The "engine" you speak of in that description is the machine itself - the Amiga or the arcade cabinet. It supports a number of colors, a size for sprites and a graphics resolution. And in that respect the word "engine" actually makes sense.

[jotd]

the "engine" from Assassin or Superfrog is probably better, even for a Robocop remake. It doesn't have parallax though.

[roondar]

Originally Posted by S0ulA55a551n

To my mind, the engine and the graphical output ( but not style) are connected.

I do not know the specs of the Robocop arcade game, but I am going to guess its higher resolution and considerably more colours on screen than robocop 2 on the Amiga.

To me the engine has to support the res, size of sprites, colours etc.

Hence no way is robocop 2 a better engine that Robocop arcade. No matter ones, views on the graphical style ?

Discuss

Ah, I'm beginning to see what you mean now. Yeah, that's not how I use the word engine. For me, the engine and the hardware it runs on are separate entities. So, you could have an engine that is limited in ways the HW isn't, or an engine that can do a great deal more than the HW can supply.

In essence, I see the 'engine' as the parts of the code that deal with making the game work and makes the game interface with the hardware. So in that respect, an engine that can support game logic things that Robocop Arcade doesn't, but can also support those game logic things the Robocop Arcade game requires is more advanced than the Robocop Arcade one - even if it it's coupled to a system that only has monochrome graphics.

The reason for this is that numbers of colours/objects/resolution usually are just hardware limitations, not normally engine ones. As an example, an engine might have support for only 10 objects on screen not because the code in the engine is actually limited to 10 objects (it could support many more), but because the system it's running on is.

[S0ulA55a551n]

Originally Posted by roondar

Ah, I'm beginning to see what you mean now. Yeah, that's not how I use the word engine. For me, the engine and the hardware it runs on are separate entities. So, you could have an engine that is limited in ways the HW isn't, or an engine that can do a great deal more than the HW can supply.

In essence, I see the 'engine' as the parts of the code that deal with making the game work and makes the game interface with the hardware. So in that respect, an engine that can support game logic things that Robocop Arcade doesn't, but can also support those game logic things the Robocop Arcade game requires is more advanced than the Robocop Arcade one - even if it it's coupled to a system that only has monochrome graphics.

The reason for this is that numbers of colours/objects/resolution usually are just hardware limitations, not normally engine ones. As an example, an engine might have support for only 10 objects on screen not because the code in the engine is actually limited to 10 objects (it could support many more), but because the system it's running on is.

I think we have just been coming at this from different angles. I do understand that an engine could move 100 objects around , but seems moot if the hardware could only display 45 objects.

I understand where you are coming from with Robocop2 , there is clearly a lot more going on in terms of gameplay etc.

[gimbal]

Let's define an example of where something could be contributed to a software engine. The engine being a piece of logic which is isolated from the game itself, it can be reused without having to change that bit of code, you just need to apply it in the game.

Parallax scrolling has been mentioned - that could be an engine feature. The hardware makes it possible to do parallax scrolling, but it's not like you flip a bit and then it scrolls. There are several factors involved. Horizontal, vertical, both? 2,3,4 layers? How fast should those layers move? How big are the layers?

That is a feature you could "engine" and reuse as-is if you did it really well. You could implement the code for the directions, you could make it configurable how many layers there are, how fast each layer moves, which graphics are used, how they are spaced.

... In modern systems where you don't need to squeeze every ounce of performance out of the game code. In a game made for the A500 or a system of equal specifications... I think the devs would choose to create a custom implementation optimised specifically towards the game code and assets. They might choose to COPY code from another game and go from there, sure. But that's not an engine, that's just copying bits of a game and altering it.

[roondar]

An example of an actual 'engine' for the Amiga (in the more modern sense) is probably Scorpion.

As for the custom vs non-custom thing... I'm on the fence. It seems to me that the term 'engine' is used all over the place. All I'm saying is that the software is separate from the hardware. Aimed at the HW, sure. But separate nonetheless.

[gimbal]

Scorpion is pretty much as close as you can get to Unreal Engine for the Amiga, yeah