New Games possible?

@wawa

Quote:

Problems happens when you trying to start any level (compain/training/anything), it say "loading level", and at some stage heavy crashes. It was the same for you ? I do not remember, but imho i not use -fomit-frame-pointer at all, will try to play with it (thanks for hint)

ps. check your mail plz, maybe will be not bad idea to try to compile game with your changes and your makefiles and all that options for gcc.

@kas1e

I guess we miss alot of stuff dependencies but i ask anyway.

Frets on Fire
http://fretsonfire.sourceforge.net/

Video:
http://video.google.com/videoplay?docid=-4385700275120314654#

Source:
http://fretsonfire.sourceforge.net/documentation/source/

@Joeled

Indeed fynny game :) But fully based on Python stuff (all those PyGame / PyGameOpenGL and so on).

While we have PyGame itself, we not have PyGameOGL module. Dunno will python based games which use PyGameOGL module fast, or the same slow as plain ones..

Anyway, for first need someone who can port PyGameOGL. And we can see how all of this works :)

@kas1e
Yes lets hope smby is willing to port PyGameOGL

a stunt car racer clone?


http://www.happypenguin.org/show?Skunks


a top down motorcycle racing game:
http://motogt.sourceforge.net/

uno! :D
http://www.happypenguin.org/show?Duo

@spotUP

Ooo..

Edit: Skunks ported - http://bit.ly/dKZyLl .. very slow (4fps on flex@800 [reuploaded, 9fps 320x240 lowres version]).. Temp link for now.

@MickJT

My "mileage" (I step on it then press ESC when the car hits the ground):


skunks-lowres cars/car1 tracks/track1

Set 320x240x24

ODE Message 3: LCP internal error, s <= 0 (s=-2.7923e-15)



**********************************************

Distance: 0.23 km
Time: 14.33 seconds
Average speed: 57.92 km/h
Average framerate: 13.33 f/s

**********************************************

System: AmigaOneXE G3 800 MHz, 512 kB L2
F1GP Amiga was locked to 8 fps when it came out, not sure about the preceding SCR.

Gameplay is weird though, you need to enter the corners at less than 30 km/h to keep the vehicle upright, not to mention a sufficient grip.

I don't know what that ODE error is, but it doesn't seem to affect anything.

You know what'd be good? Some sort of zooming tool for any public screen, like Compiz Fusion can do on Linux. That way you can get a faster FPS by lowering the res, then zooming in.

Anything like that possible or available for OS4.1?

@MickJT

Pretty funny one. Looks very similar by desing, sounds and idea as simcar. Simcar a bit better than skunks in terms of control, but skunks are nice too, i have some fan with it for now. There is my benchmarks:

320x240 with cars/car1 tracks/track1 : 16 fps
640x480 with cars/car1 tracks/track1 : 7 fps

strange that is so slow , looks very close to simcar (which are fast, and its just plain SDL). Looks like that ODE itself are unoptimised a bit.

@kas1e

isnt simcar and skunks by the same person?

@derfs
Quote:

Yep, you are right , they boch done by mattey_v. Well, anyway on screenshots these games looks better than in real :) No music, boring sounds, no any kind of menu, just some code to handle cars/tracks.

@kas1e

ODE provides physics maths routines. I doubt that has anything to do with the difference between 320x240 and 640x480. Unless you referring to some other aspect of the game other than framerate?

X-Moto uses ODE and it's fast.

To be blunt and without respect to anyone that Skunks game looks like a pile of *insert your favourite explicative here*.

Even the original Stunt Car Racer ran at more than 6-7fps. Amiga doesn't need dodgy 8-bit games from the 80s, it needs 32-bit games from the 90s/00s.

Surely SpotUp was posting this 'suggestion' as some kind of joke!

@djrikki

From screenshot was expected that it will be very fast, so can be funny. But of course, such 80th game and at so slow speed are strange. If that not ODE problem, then something wrong with game-code at all. Some busy loops maybe, or kind.. Or maybe its just very very alpha.

But yep, without normal sound, without music, and so slow, its not interesting, but thanks to MickJT anyway for try :)

@MickJT

Btw, MotoGT looks pretty nice/funny on video , maybe worth of porting. Not so modern and quality, but with music, sounds and with nice design. Its done on c++ and use SFML libs. Maybe you can try ?

@kas1e

SFML needs to be ported by someone who can code. It expects X11 and Linux joystick headers... (and unicode, but that likely can be commented out easily).

For those wondering where the source is, it's SFML-1.6-sdk-linux-32.tar.gz

@kas1e

Looks nice.

@all
I compiled Warzone 2.0.8rc1 (2 years old release). I choice it because Fab port it as latest version (as i see on his page), and after that looks like authors introduce all that problematic stuff.

For now have binary, but it crashes heavy on loading, so need some time for debuggin/etc. But i have binary, that mean that half of problem in the past.

@kas1e

Bravo

This was "my" project, but it seems you anticipate me

If needed we can merge from my configure and see if we can working togheter in some kind

@samo79 and kas1e

Thanks for looking on warzone

For sure, not aproblem is not the last version but explain why on the readme (if this game for AOS4 will be finished) for not receiving lots of requester for the last version

@samo79

Quote:

If you want i can send you current source code and you can continue with it, and fix bugs in code because of which it crashes for now :) I will be only happy if someone can make a working binary, and i will do something else :)

Quote:

All that configure/makefiles different for all the versions of all the games. Purposes of configure: making makefiles. Purposes of makefiles: build all the sources to the objects with right params (which founds by configure) and make the final linking. I.e. if version 2.0.8 have that and that sources, and that and that options for compilation/linking, then other and newer versions will have new objects, new options, new files (for which, you need of course new configurations and new makefiles).


Building of makefile , it's the most easy thinks in all the porting. There you not need to know how to code, you just need understand what files to compile, and how. And you can easyly write your own bat_file , where will be all the lines , like:

Quote:

Of course when projects start to be compilcated, worring with bat scripts can be not so easy, but still, if configure/makefiles not works by some reassons, it can be done like that.

By all of this i mean that there is nothing what we can merge, because there its the same as merging x86 assembler and 68k assembler. Of course not the same difference, but almost like that make no sense.

But porting (as some ppls start to think in last time), its not only ./configure; make. None of the big-projects can be compiled like this imho, and working after that. The real "work" start when you even start to compile objects: some includes are wrong, some includes are not present on current SDK, some functions are redefined, some symbols in aos4 sdk are reserved, and project can't use the same names, some functions are defined at wrong place, some "extern" not done, and on our SDK it suck, but works on win32/linux ones, some types are defind in aos4 sdk in exec/types.h, but in project it redefined (like BOOL, int32, uint32 and so on), some fucntions just not present at all (like wchar or kind) and so on and so on. And that only about compiling an objects. Then linking (mostly the ease part, just need to found right libs, but some times there is heavy problems as well, but not so offten). Then you have a binary, which for sure will not works, crashes, and then, real work starts : understand why it crashes, found by debugggin (or by printfs() ) part in code where it crashes, understand what its do, and fix it. There you need to know programming anyway.


With that version of Warzone , there was few bad externs, few redefinations of types, some redifinations of some symbols (game use some names which are reserved in aos4 sdk, like for example SCREENTYPE value). Also on linking stage it fucks from time to time in terms of all that lex/bison stuff, so i a bit change few files to make it linking.

And then i have binary, which on running ask for rc8/users/default directory, then after creating it runs, and crashes on the function "scan data dirs", which mean there is all those problems with ./ / PROGDIR: and alt (i hope there is only that problems). So need to build debug version, and check it more deeply.

The most interesting thinks as well will starts after you will have "almost working binary". It will runs , show something for example, and then crashes. Or have bad textures, and then, need to worring about opengl, warp3d , found where is problems and why it buggy and alt. I am almost sure that "scan dirs" bug it's not the last one which we will have there :)

Btw, i use crosscompiler setup on win32/cygwin to make all makefiles , and for compilation/linking as well, because our bison (old one, and new one, which port salas00 in warzone thread), not works because of some error, while crosscompiler one works fine.

@Mrodfr
As far as i know, 2.0.8rc1 are pretty playable on morphos, and in 2008 year it was one of the best games for morphos (in some charts). So even that version will be not bad imho.