| Interesting 3D Racing Game for Vampire? | page 1 2 3 4
|
|---|
|
|---|
| | 
Vojtěch Salajka
Posts 15
05 Jul 2022 00:11
| I decided to release the source of MultiRacer:
EXTERNAL LINK
I am interested in what this community can do with it.In case anyone feels this is beneficial to them and wanted to give back, then please send monetary support to Ukraine through a charitable organization of your choice. I am sure many already did, but a continuous support is needed.
| |
| | 
Steve Ferrell
Posts 424
05 Jul 2022 22:38
| I tried compiling under Linux but I get linker errors. Maybe some Amiga users will have better luck with an Amiga build.
| |
| |
Vojtěch Salajka
Posts 15
06 Jul 2022 08:48
| The build is tested on Linux and Windows mingw32 (but I did not include Windows makefile, because Windows, you know... not the best system for hassle-free building stuff). So it should work. When reporting error, please always include details about the OS, HW and especially full error message. From what you are stating now, it could be anything from you not having installed required dev packages, the libraries having different name in your particular flavor of Linux, to a real issue that needs resolving.
| |
| |
Vojtěch Salajka
Posts 15
06 Jul 2022 17:26
| One more note:
Build for Windows is provided along with the openmrac.dat file here: EXTERNAL LINK
The openmrac.dat file can be taken from there if anyone has trouble generating it from the data in OpenMRac-data repository.
| |
| |
Steve Ferrell
Posts 424
08 Jul 2022 00:25
| I'm attempting a build on Ubuntu 22. When doing a 'make' i.e. make -f Makefile.linux I get linker errors complaining about undefined symbols even though I've installed all the required dev libraries and headers. Here's a snippet where it complains about missing SDL symbols. It also complains about missing symbols for every other required library such as OpenAL, freeglut/OpenGL, etc...even though they were properly installed.
SDL snippet:
/usr/bin/ld: main.o: in function `my_exit(int, bool)':
main.cpp:(.text+0x232): undefined reference to `SDL_JoystickOpened'
/usr/bin/ld: main.cpp:(.text+0x259): undefined reference to `SDL_Quit'
/usr/bin/ld: main.o: in function `EnableOpenGL(bool, bool, unsigned int, unsigned int)':
main.cpp:(.text+0x29b): undefined reference to `SDL_GetVideoInfo'
/usr/bin/ld: main.cpp:(.text+0x2ba): undefined reference to `SDL_GL_SetAttribute'
/usr/bin/ld: main.cpp:(.text+0x2ce): undefined reference to `SDL_GL_SetAttribute'
/usr/bin/ld: main.cpp:(.text+0x2f2): undefined reference to `SDL_SetVideoMode'
/usr/bin/ld: main.cpp:(.text+0x310): undefined reference to `glViewport'
/usr/bin/ld: main.cpp:(.text+0x333): undefined reference to `SDL_GL_SetAttribute'
/usr/bin/ld: main.cpp:(.text+0x346): undefined reference to `SDL_GL_SetAttribute'
/usr/bin/ld: main.cpp:(.text+0x351): undefined reference to `SDL_GetError'
/usr/bin/ld: main.cpp:(.text+0x391): undefined reference to `SDL_GetError'
End snippet
Upon looking in the Makefile.linux, I noticed that your LINK statement is g++ rather than ld. When I change the link directive to LINK = ld, instead of LINK = g++, the link errors for OpenAL, OpenGL, SDL, etc. go away but then I get link errors for the math library:
ld: cam.o: undefined reference to symbol 'sincosf@@GLIBC_2.2.5'
ld: /lib/x86_64-linux-gnu/libm.so.6: error adding symbols: DSO missing from command line
Adding -lm to the following gets me past the math library link errors:
LFLAGS = -lSDL -lGL -lopenal -ljpeg -lpng -lm -s
But then I get to the following libc error:
ld: gbuff_in.o: undefined reference to symbol '__fgets_chk@@GLIBC_2.4'
ld: /lib/x86_64-linux-gnu/libc.so.6: error adding symbols: DSO missing from command line
libc.a is definitely in my /lib/x86_64-linux-gnu/ directory so at this point I'm unsure what's wrong so I gave up.
| |
| |
Vojtěch Salajka
Posts 15
09 Jul 2022 00:06
| Maybe changing this $(TARGET): $(OBJS)
$(LINK) -o $(TARGET) $(LFLAGS) $(OBJS) to this $(TARGET): $(OBJS)
$(LINK) -o $(TARGET) $(OBJS) $(LFLAGS) could help, but I'm not sure. I am using Manjaro and haven't seen Ubuntu for years.
| |
| |
Steve Ferrell
Posts 424
09 Jul 2022 01:03
| Thanks! Yes, that worked. Here's a Makefile.ubuntu for those using building with Ubuntu
---------------------------- CFLAGS = -O2 -Wall -Wextra -DDIR_OPENMRAC_DAT=/usr/share/openmrac/ -fno-exceptions -fPIC
LFLAGS = -lSDL -lGL -lopenal -ljpeg -lpng -lm -s
CXX = g++
LINK = g++
TARGET = openmrac
# echo -n "OBJS = "; ls *.cpp | sed 's/.cpp$/.o/g' | tr '\n' ' ' ; echo
OBJS = 3dm.o cam.o car2d.o collider.o controls.o cstring1.o datkey.o fopendir.o gameaux.o gamemenu.o gamemng.o gamemng_frame.o gamemng_load.o gbuff_in.o ghost.o glext1.o glhelpers1.o gltext.o gridlayout.o gui.o guifont.o load_texture.o main.o mainmenu.o matmng.o mtrxinv.o octopus.o particles.o pict2.o pict2_jpeg.o pict2_png.o rand1.o rbsolver.o settings_dat.o settingsdialog.o skysph.o soundmng.o triboxint.o .PHONY: all clean install uninstall all: $(TARGET) clean:
rm -f *.o $(TARGET) %.o: %.cpp *.h
$(CXX) -c $(CFLAGS) $< $(TARGET): $(OBJS)
$(LINK) -o $(TARGET) $(OBJS) $(LFLAGS) install: $(TARGET)
sudo rm -f /usr/bin/openmrac
sudo cp openmrac /usr/bin/openmrac uninstall:
sudo rm -f /usr/bin/openmrac
| |
| |
Vojtěch Salajka
Posts 15
09 Jul 2022 15:34
| It works for me with your tweaks, so I will include it those in the generic Linux makefile. Edit: It's in:
EXTERNAL LINK
Please check if all is working now. Thanks!
| |
| |
Steve Ferrell
Posts 424
09 Jul 2022 19:15
| I started over fresh by cloning the game and the data repos and everything builds just fine.
| |
| | 
Tommo Noorduin
Posts 136
11 Jul 2022 13:44
| Vojtech Salajka wrote:
|
I decided to release the source of MultiRacer
|
Steve Ferrell wrote:
|
I started over fresh by cloning the game and the data repos and everything builds just fine.
|
| |
| | 
Roy Gillotti
Posts 524
11 Jul 2022 16:51
| I take it this will still need some kind of form of OpenGL working on the Vampire to get this working at any decent speed.
| |
| |
Steve Ferrell
Posts 424
12 Jul 2022 04:59
| Yes, although linking with StormMesa 68K V2.0 might suffice/replace an OpenGL link library requirement. EXTERNAL LINK
SDL exists for 68K but I don't see an OpenAL implementation on Aminet for 68K. OpenAL could possibly be dropped as it's just for 3D audio.I've never used StormC so I have no idea how compatible it is with Vojtěch's source code. I program mainly for Linux, Windows and Mac and haven't programmed an Amiga in years but I'm sure there are still plenty of Amiga 68K programmers out there who should be able to make this work.
| |
| | 
Kenji Irie
Posts 86
12 Jul 2022 06:19
| OpenAL exists for 68k, but it's very slow. Arczi used it for the initial C&C port. Personally, I would remove it for the meantime, and then code direct to SAGA audio when required.
| |
| |
Vojtěch Salajka
Posts 15
15 Jul 2022 16:30
| Audio engine should not be too concerning. I have added my own "MiniAL" implementation that replaces OpenAL. It is rudimentary, yet sufficient for the purposes of OpenMRac:
EXTERNAL LINK
It uses SDL 1.2 backend and is already working, so anyone can go from there and make it better e.g. by incorporating whatever hardware resources are available on a given platform
| |
| |
Vojtěch Salajka
Posts 15
25 Nov 2022 08:47
| I have just pushed SDL2 port of OpenMRac:
EXTERNAL LINK
I would also like to point out again that OpenAL is optional and the game can use standard SDL audio instead (I have made my own wrapper for it).It seems the last missing piece of the puzzle is a working 3D accelerated OpenGL implementation?
| |
| | 
Steffen Häuser
Posts 60
10 Jan 2023 11:56
| Artur Jarosik wrote:
|
Hi Vojtech, I have ported some OpenGL games to AmigaOS 3.x including Cube1&2 EXTERNAL LINK
We have also Quake 1&2&3 ports.
If your game doesn't use more GL functions than those than it would compile straight (I have working SDL, OpenAL and MiniGL).
|
Is this including 3D Hardware support with the custom chip of the Vampire ? Or a purely software solution ? I believe at least a "Mini-MiniGL" with hardware support is required for the platform to have a future (like: Not all GL calls supported, not all texture formats, even more limited than Hyperion's MiniGL is ABSOLUTELY ENOUGH FOR NOW). I definitely would be willing to discuss this more in private and what could be done. As to what I think should be supported and stuff (but if you ported Quake 2/3 in a - I assume - software based solution you probably already know). As to the Vampire I am still "on the fence". I prefer PPC platforms like my good old x1000 (nothing which should be discussed in this thread) but I am open to read about other things, still I think what you guys did is FUCK*** IMPRESSIVE! I am currently not supporting your platform, but as I said - I am "on the fence" there. Implementing a special renderer for your hardware is DEFINITELY THE WRONG WAY. Make a static linker library with a subset of OpenGL, and make this also available to other developers. It is what we did when we did Heretic2 and Shogo 20 years ago, and we never thought it a mistake. Quite the contrary. Not require people to do the same AGAIN AND AGAIN for every new game. OpenGL is the standard! Feel free to pass me an email. You might wonder why I write in such detail on it despite not supporting your platform currently. I still wish your platform everything good despite not personally supporting it, and want to give some advice out of personal experience of past decades ;-) Best regards,
Steffen Haeuser (author of Amiga Versions of Heretic2, Descent:Freespace and some other 3D Games)
tirionareonwe@gmail.com
(Note nothing what I wrote here is in any way a Hyperion statement, I am no longer working for Hyperion though I am in a complicated way still working with them and sometimes doing something for them - but my public comments are my own)
| |
| | 
Thellier Alain
Posts 143
10 Jan 2023 17:17
| The simpler would be to have a Warp3D driver for maggie3D As the two accelerated opengls for Amigas 68k use it for hard rendering (MiniGL, StormMesa) We (me and others) fixed several issues with StormMesa the fixed version is aminet/stormmesa2010
| |
| | 
Gunnar von Boehn
(Apollo Team Member)
Posts 6263
11 Jan 2023 09:44
| thellier alain wrote:
|
The simpler would be to have a Warp3D driver for maggie3D
|
Yes, something like this will for sure come.
I think everyone who saw the existing Amiga 3D game demos which use Maggie already today: "Apollo 3D racer" and "Apollo Dungeon Master" is totally thrilled about the 3D features.
There are many good games that can benefit from the 3D acceleration. Wipeout, Tomb raider, and many more come to mind.
Of course a good Amiga coder will not just "compile" a game like Tomb raider but will want to make use of the key advantages of the Amiga architecture - where Amiga is better than a PC. Making these ports also better than the PC version. I think good coders for sure will use Amiga DMA to play back music using zero CPU. Audio DMA being just one example of the advantages of the general Amiga design. As you know the V4 Amiga architecture offer 16 Amiga Audio DMA channel, each being able to play back CD quality music. Thsi is awesome for making games sound good and run fast.
I look forward to see in the near future many existing 3D titles which use the advantages of the Amiga hardware.
| |
| |
Steffen Häuser
Posts 60
11 Jan 2023 15:11
| Gunnar von Boehn wrote:
|
thellier alain wrote:
|
The simpler would be to have a Warp3D driver for maggie3D
|
Yes, something like this will for sure come. |
This would help a lot on possible projects. Either porting Warp3D or replacing Warp3D calls in existing MiniGL (might even make sense in looking at an older version of MiniGL to make it "simpler"/"less effort").
I think everyone who saw the existing Amiga 3D game demos which use Maggie already today: "Apollo 3D racer" and "Apollo Dungeon Master" is totally thrilled about the 3D features.
|
Still, it is no good idea to have to reinvent the wheel every time. Especially as GL is an established standard (note hat future game sources coming from GL Direction probably will require a shader architecture - though right now enough is available which doesn't - even a reduced functionality MiniGL - Mini-MiniGL - would be enough).
Of course a good Amiga coder will not just "compile" a game like Tomb raider but will want to make use of the key advantages of the Amiga architecture - where Amiga is better than a PC. Making these ports also better than the PC version. I think good coders for sure will use Amiga DMA to play back music using zero CPU. Audio DMA being just one example of the advantages of the general Amiga design.
|
From the architecture of such games there are not many areas where they would have advantages of such. And DMA Audio replay - in the speed at the end I doubt it will make a big difference. If I completely switch off sound in one of my gameports (so that it is not even called) the fps-rate is roughly the same. Still - the hardware you created is AWESOME ;-) Someone mentioned StormMesa above - is the new version usable for games in the meanwhile ? Does it have 3D Hardware Support ? The original one - you could compile a game with it but got like 1 fps, massively slower than software rendering. Did not try the new one.
Steffen Haeuser
| |
| |
Gunnar von Boehn
(Apollo Team Member)
Posts 6263
12 Jan 2023 05:53
| Steffen Häuser wrote:
|
From the architecture of such games there are not many areas where they would have advantages of such.
|
Let me give you some examples of areas where I would look at:
1) The V4 Amiga Audio hardware offers you 16 DMA based channels.
Each of these channels can play full stereo samples,
and can stereo position each of the sample.
Stereo position sound effect is very nice for games but cost some CPU if you mix them by hand. The hardware mixing can save millions of CPU instruction per second.
2) The V4 Amiga Hardware can display all memory.
For games that softrender a screen - like for example what DOOM does, you not need to memcopy the screen each frame to the gfx card.
Not needing to copy the screen will give a major saving compared to other systems.
3) Games and Demos doing software rendering can highly benefit of the 68080 AMMX "TEX" special instruction.
The "TEX" instruction makes simple texture mapping much faster compared to using "normal" CPU instructions.
4) And of course even a bigger boost you can get by using Maggie 3D acceleration.
5) FPU code of the game should be written to bulk process the date and to unroll the calculations to benefit of the FPU advanatages.
Let me explain why. As we all know the external 68881 FPU was very slow needing many cycles for operation.
We speak here about 50-100 cycle per FPU operation.
This is very slow and not good enough to make 3D games like we want now.
68040 and 68060 have an integrated FPU. This highly improves performance. With the introduction of the 68040, the FPU operations were speed up to 5 cycles. This a major speed up compared to 68881.
But neither the 68040 nor the 68060 FPU were fully pipelined.
The first and only 68K CPU with a fully pipelined FPU is the 68080.
Fully pipelining the FPU allows you to do an FPU instructions each cycle. This is much faster than 68040 /68060 were.
To benefit from this you want to unroll your work loop.
As you know the 68040/60 only had 8 FPU registers. And 8 register are not enough to unroll work loops.
The 68080 fixes this situation, the 68080 provides 32 FPU registers.
The 32 FPU registers allow you to nicely unroll heavy duty FPU code to get maximum performance.
| |
|
Running Games and Apps.