English Amiga Board


Go Back   English Amiga Board > Coders > Coders. General

 
 
Thread Tools
Old 08 September 2014, 12:46   #41
Cowcat
Registered User
 
Join Date: Apr 2013
Location: Mallorca
Posts: 293
As promised, the whole code.

You need to compile the old minigl aminet sources using the modded code provided (it is exactly the same lib/mod used on BlitzQuake 2014 + fixes). A must.
You need posix lib from vbcc packages + includes, also Amitcp includes.
Compile the dll lib of Quake2, of course.

Things to still be tested/fix:
The net code: Don't know if it works, and some code still messed up with the includes.
The renderercache for warpos.
Probably remove the posix lib & make 100% free unix code (used in few places).
A better makefile: Not 100% proof-include-depends.

Feel free to use it & make it better (already testing new code).

Last edited by Cowcat; 21 November 2017 at 15:47.
Cowcat is offline  
AdSense AdSense  
Old 01 October 2014, 23:34   #42
matthey
Banned
 
Join Date: Jan 2010
Location: Kansas
Posts: 1,284
@Cowcat
I compiled a new version of the c99 math libs for vbcc with a fix to the m060.lib and m060s.lib. Frank Wille found and fixed a problem that caused the 68020 versions of some functions (using trapped integer 64 bit instructions) to be used instead of the 68060 versions. The new archive is here:

http://eab.abime.net/showthread.php?t=74692

Also, Cosmos pointed out the following link to MiniGL in case you didn't know about it.

http://www.hyperion-entertainment.bi...iGL/trunk/src/
matthey is offline  
Old 02 October 2014, 13:26   #43
Cowcat
Registered User
 
Join Date: Apr 2013
Location: Mallorca
Posts: 293
@matthey
Fixes are cool

Yep, I'm aware of that trunk minigl code: Sometimes I take a look if there's something to benefit the old code, but it's radically different and a daunting task to reimplement the whole thing.
Nowadays I'm cleaning the code +fixes (again) and trying different implementations of different Quake codes from all sources possible: From Yamagi to last 2.3.24 quake2.

My newest WarpOS version is to my tests slightly faster, but seems to be nothing gained for 68k version given the new code (weird).
Recently gl_shadows option uses vertex arrays + fixes on minigl code, so there's room for improvement. Also some of these ideas can be probably applied to a BlitzQuake future version. We'll see
Cowcat is offline  
Old 04 October 2014, 06:07   #44
Michael
A1260T/PPC/BV/SCSI/NET

Michael's Avatar
 
Join Date: Jan 2013
Location: Moscow / Russia
Posts: 600
Sweet. Can't wait for an update and hopefully some more fixes ;-)
Michael is offline  
Old 11 October 2014, 17:58   #45
Cowcat
Registered User
 
Join Date: Apr 2013
Location: Mallorca
Posts: 293
@michael
New things & maybe a small speed boost.

Cool option for a future release: Third person view camera.
Attached Thumbnails
Click image for larger version

Name:	3dcam1.jpg
Views:	231
Size:	246.5 KB
ID:	41855   Click image for larger version

Name:	3dcam2.jpg
Views:	220
Size:	174.0 KB
ID:	41856  
Cowcat is offline  
Old 12 October 2014, 20:25   #46
Michael
A1260T/PPC/BV/SCSI/NET

Michael's Avatar
 
Join Date: Jan 2013
Location: Moscow / Russia
Posts: 600
Hmm... nice. Was not it available before ? Even Q1 used it in many places with the mods.
Michael is offline  
Old 13 October 2014, 00:35   #47
Cowcat
Registered User
 
Join Date: Apr 2013
Location: Mallorca
Posts: 293
@michael
Not in the Q2 original sources exists that option, even for some later updates. It's a fun option for tweak & play, but still some things to do for a new release.
Cowcat is offline  
Old 03 November 2014, 17:37   #48
Cowcat
Registered User
 
Join Date: Apr 2013
Location: Mallorca
Posts: 293
New warpos upload:

Two versions of glnolru inside (ref_gl is faked name). Test one against the other & old quake2 versions. The "ref_gl" has reenabled code that was not complete at the time plus workaround for "multimodedrawelements".
Changed "gettimeofday" for warpos (now uses getsystimeppc).
Original ref_gl still is a problem on warpos (anyways is slow & doesn't clean resources as old m68k version).
As comented before gl_shadows option is now faster & fixed (no impossible shadows, no shadows on blasters, etc).

New options: ThirdPersonView camera.
- cl_3dcam, cl_3dcam_angle, cl_3dcam_dist. Some values to see the effect: 40 for angle & 70 for dist. (Now you're a poligon )

- cl_drawfps (a simple one).

There's an option that was disabled by default "gl_closeworkbench": If you have problems with full display (some corruption) or low memory maybe enable it, but you loose multitasking (no switch to workbench screen).

Also a new warp3dppc version I've been using for a while.....
Attached Files
File Type: lha Quake2_wos_beta2.lha (889.6 KB, 103 views)
File Type: lha Warp3DPPC_beta3.lha (20.1 KB, 87 views)
Cowcat is offline  
Old 05 November 2014, 18:46   #49
Cowcat
Registered User
 
Join Date: Apr 2013
Location: Mallorca
Posts: 293
Test it.
Attached Files
File Type: lha Quake2_060_beta2.lha (721.7 KB, 98 views)
File Type: lha Quake2_040_beta2.lha (744.6 KB, 80 views)
Cowcat is offline  
Old 05 November 2014, 21:00   #50
Michael
A1260T/PPC/BV/SCSI/NET

Michael's Avatar
 
Join Date: Jan 2013
Location: Moscow / Russia
Posts: 600
Quake2_wos_beta2 (with original W3D)
ref_gl - 45.5s - 15.1 fps
ref_gl_no_lru - 47.2s - 14.3 fps

no optimizations, just run it as is, I think with same settings HQ2 gives 42.4s - 16.2 fps
but really need to play around with this toys to see how things work and what effects what.
Michael is offline  
Old 07 November 2014, 15:59   #51
Cowcat
Registered User
 
Join Date: Apr 2013
Location: Mallorca
Posts: 293
Beta2 source:
New minigl workaround/fix used for faster shadows: See what it is all about on my old Warpos Minigl Blues thread & some inline vbcc w3d code just in case.

Cleaned sources: All checks for stereo googles interface are disabled (somebody has one?)
New code for 3dcam & shadow test is located on client dir (taken from kmquake2) & some code is left there (disabled )for future use. A lot to do with that.
Some optimized (?) code on a q_shared alternative version (maybe is usefull to try), besides some silly things I used for this new version.

Important for coders: Every new version invalidates saved gaming & every modification on important headers leads to unexpected crashes & bad behaviour. Is the way it is with Q2, so you need a full recompile (probably you know this already).

Last edited by Cowcat; 21 November 2017 at 15:46.
Cowcat is offline  
Old 08 November 2014, 18:52   #52
matthey
Banned
 
Join Date: Jan 2010
Location: Kansas
Posts: 1,284
Quote:
Originally Posted by Cowcat View Post
Test it.
I tried out the Quake 2 68060 build a bit. Aiming with the mouse seems easier. I can put the dot on the enemies now except when the game slows down and gets jerky. It might be quite playable if I try some of the speedup settings suggested in this thread. I can also use stairs without having to jump on them. Overall, the game is less frustrating and more playable. I didn't have any crashes in my short trial although I didn't check for MuForce hits. I do still have the color distortion issue I mentioned earlier and sometimes I hear clicking sounds which I didn't notice in the earlier build (probably just me not noticing). The sound effects are generally low quality and cut out when the display is jerky for an extended period which may be part of the problem. I can play with the settings and/or optimize some more vbcc code to free some CPU performance. Nice job!
matthey is offline  
Old 09 November 2014, 11:58   #53
Cowcat
Registered User
 
Join Date: Apr 2013
Location: Mallorca
Posts: 293
@matthey
Thanks !

To alleviate the mouse jerkiness I use "m_filter 1" & "cl_maxfps 25" (those vars aren't recorded on config.cfg when out).

My config nowadays looks like this:
gl_texturemode GL_NEAREST
gl_drawparticles 2
gl_skipparticles 2
gl_particle_size 20
gl_mintriarea 2.5 -> this value is for 512x384 screen. On blitzquake thread the formula to round the needed value for other screen modes is explained.

gl_flashblend 1

Of course gl_vertex_arrays is on "1" by default & in my case gl_ext_multitexture is on "0".

Another thing is "r_vertexlighting 1" that bypasses....lights !, if you go only for speed.

Some simple optimizations that work can be done on the sources: Manual unrolling for example on gl_mesh.c -> DrawAliasFrameLerp (those i<3 loops) or on gl_light.c on AddDynamiclights,R_buildlightmap, etc,etc. Just experiment: Unexpected unrolling in some places didn't make the binary bigger, quite the contrary (at least on warpos).

In fact I had a faster warpos version time ago but messed to much with it and probably ended with the relative 68k version being slower....so I had to redo all quite a few times.
Another option maybe for 68k could be an eclock version for gettimeofday on q_shamiga.c, just like the hack I did with getsystimeppc.

Note: Still don't know those color issues...
Cowcat is offline  
Old 10 November 2014, 06:40   #54
matthey
Banned
 
Join Date: Jan 2010
Location: Kansas
Posts: 1,284
Quote:
Originally Posted by Cowcat View Post
To alleviate the mouse jerkiness I use "m_filter 1" & "cl_maxfps 25" (those vars aren't recorded on config.cfg when out).

My config nowadays looks like this:
gl_texturemode GL_NEAREST
gl_drawparticles 2
gl_skipparticles 2
gl_particle_size 20
gl_mintriarea 2.5 -> this value is for 512x384 screen. On blitzquake thread the formula to round the needed value for other screen modes is explained.

gl_flashblend 1
I tried your settings and didn't notice any difference in quality but it was enough faster that I had to turn the mouse sensitivity down more. It's pretty playable now at 512x384 in 16 bit without reducing the screen size.

Quote:
Originally Posted by Cowcat View Post
Another thing is "r_vertexlighting 1" that bypasses....lights !, if you go only for speed.
I tried turning it off to see if my color distortion problem was related to lighting. No difference.

Quote:
Originally Posted by Cowcat View Post
Some simple optimizations that work can be done on the sources: Manual unrolling for example on gl_mesh.c -> DrawAliasFrameLerp (those i<3 loops) or on gl_light.c on AddDynamiclights,R_buildlightmap, etc,etc. Just experiment: Unexpected unrolling in some places didn't make the binary bigger, quite the contrary (at least on warpos).
I don't know how unrolling would shrink the executable size. Sometimes reordering, simplifying or changing the data types of variables inside a loop will make a big impact though. It would be better if compilers were smart enough to do it because some optimizations are CPU dependent. The 68060, for example, benefits very little from loop unrolling and may actually be slower if a lot of loop unrolling kicks code out of the ICache. The 68060 is the rare exception as most other processors are not as efficient at loops to perform the same magic. Think how much ICache could be saved if loops didn't need to be unrolled.

Quote:
Originally Posted by Cowcat View Post
In fact I had a faster warpos version time ago but messed to much with it and probably ended with the relative 68k version being slower....so I had to redo all quite a few times.
Another option maybe for 68k could be an eclock version for gettimeofday on q_shamiga.c, just like the hack I did with getsystimeppc.
What is faster for the 68040 might not be for the 68060. The 68060 may be more like modern processors but the RISC PPC is quite a bit different too.

Quote:
Originally Posted by Cowcat View Post
Note: Still don't know those color issues...
I attached a screen grab (grab.png) with a picture of the distorted colors on some barrels. There are some places where the color distortion is this bad but there are also some places that there doesn't seem to be a problem. I tried gl_forcedepth "16" but it didn't help. I wish there was a gl_endian setting that would choose LE or BE gfx modes. The Elbox 2D Avenger driver has color distortion problems in BE modes on the Voodoo 4.
Attached Thumbnails
Click image for larger version

Name:	grab.png
Views:	178
Size:	209.5 KB
ID:	42150  
matthey is offline  
Old 10 November 2014, 10:46   #55
Cowcat
Registered User
 
Join Date: Apr 2013
Location: Mallorca
Posts: 293
@matthey
Quote:
it was enough faster that I had to turn the mouse sensitivity down more.
Cool. I talked about my mouse settings & just yesterday found that newer optimizations made unnecessary to mess with the options & felt like playability was much better. Tempted to upload new ref_gl's for all versions(we'll see).....but

Quote:
The 68060, for example, benefits very little from loop unrolling and may actually be slower if a lot of loop unrolling kicks code out of the ICache.
.....probably is what I felt with the 040 version too (060 is out of question for me). Some Q2 code out there is modded that way but I experienced that applying some of those unrollings in other places (like for example on pmove.c on qcommon dir) you end with a totally wrong slow code .

Quote:
I wish there was a gl_endian setting that would choose LE or BE gfx modes.
Now I understand with the picture. A simple toggle could be made for bypassing all those "littlefloat, long, short" endianess checks whenever a model-entity colour load happens. But of course, when is needed or not is the problem as you say that sometimes there's no distortion.

Last edited by Cowcat; 10 November 2014 at 12:25.
Cowcat is offline  
Old 14 November 2014, 15:15   #56
Cowcat
Registered User
 
Join Date: Apr 2013
Location: Mallorca
Posts: 293
More wood:

Some new code to apply & try for the gl dlls. Only made this for glnolru so apply to the normal gl.
Besides some attemp to unroll some of the loops (more or less luck), there's an awesome optimization on gl_rsurf.c (r_recursiveworldnode) that makes more responsive gameplaying, for example less lag is noticed (or very few) on first level when you go out in open air.
Attached Files
File Type: lha glnolru_mod.lha (48.1 KB, 76 views)
Cowcat is offline  
Old 20 December 2014, 00:32   #57
Cowcat
Registered User
 
Join Date: Apr 2013
Location: Mallorca
Posts: 293
Did someone notice that 3D models work for the new thirdcamera option?

I admit didn't know it
Just using the players/male dir & files from Quake2 demo pak (grunt, skin, tris,weapon,etc) does the trick -> Full thirdperson playing.
"developer" command option show what is needed.

Also a "hidden" cl_3dcam_alpha option (that I didn't tell but it was on last compile) makes the model transparent when camera is on back.
Attached Thumbnails
Click image for larger version

Name:	grunt.jpg
Views:	177
Size:	67.0 KB
ID:	42486  
Cowcat is offline  
Old 17 January 2015, 00:13   #58
matthey
Banned
 
Join Date: Jan 2010
Location: Kansas
Posts: 1,284
@Cowcat
You have been quiet lately. The new version of vbcc 0.9d is out now and there is already a small 68k FPU math bugfix here:

http://eab.abime.net/showthread.php?p=969253

Has the new version of vbcc been working ok? Have you noticed any improvements?
matthey is offline  
Old 18 January 2015, 22:57   #59
Cowcat
Registered User
 
Join Date: Apr 2013
Location: Mallorca
Posts: 293
@Matthey
Happy new year mate !

Yep. Realized that the new vbcc version appeared & still have to do a full 68k test. Some funny mistakes by me with newer vasm made me email Phx for nothing

The "-nowarn=62" wasn't on my config (I didn't copy the new ones), so one thing lead to another So now if in any makefile is called vasm you need that option with new vbcc 9d pack, just to get rid of those innocuous "warns".

Hope that those who download the sources have a working Q2 binary or started to fix some of the code like network (untested) or adding newer things: Say something !

Busy with some ppc asm code for Q2 that could be added for educational purpose (frsqrte). Don't know if it really improves performance, but those ideas were already used in BlitzQuake by Phx.

Don't really know why but my new wos binary is someway faster: Is the new code added?, the warp3dppc mod ? We'll see for 68k.
Cowcat is offline  
Old 18 January 2015, 23:21   #60
matthey
Banned
 
Join Date: Jan 2010
Location: Kansas
Posts: 1,284
Quote:
Originally Posted by Cowcat View Post
@Matthey
Happy new year mate !

Yep. Realized that the new vbcc version appeared & still have to do a full 68k test. Some funny mistakes by me with newer vasm made me email Phx for nothing

The "-nowarn=62" wasn't on my config (I didn't copy the new ones), so one thing lead to another So now if in any makefile is called vasm you need that option with new vbcc 9d pack, just to get rid of those innocuous "warns".
I did notice the change in the config and copied it over but I wasn't getting warnings before that. I am using an even newer version of vasm than in vbcc 0.9d though.

Quote:
Originally Posted by Cowcat View Post
Hope that those who download the sources have a working Q2 binary or started to fix some of the code like network (untested) or adding newer things: Say something !
I would play with it if I didn't have other projects. I haven't even tried Arti's gl HHexen yet.

Quote:
Originally Posted by Cowcat View Post
Busy with some ppc asm code for Q2 that could be added for educational purpose (frsqrte). Don't know if it really improves performance, but those ideas were already used in BlitzQuake by Phx.
For other's educational learning or for yours?

Quote:
Originally Posted by Cowcat View Post
Don't really know why but my new wos binary is someway faster: Is the new code added?, the warp3dppc mod ? We'll see for 68k.
There are several changes in vbcc 0.9d that could help the speed. From the changelog, it looks like the PPC mostly received bug fixes. The 68k side received a few optimizations though .
matthey is offline  
AdSense AdSense  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
ADF-Workshop (formerly DMS-Workshop) Crashdisk project.TOSEC (amiga only) 134 28 July 2017 19:39
Anim Workshop Manual _amigan request.Other 0 03 December 2012 16:30
Looking for Anim Workshop 2.0 amigagenie request.Apps 12 10 July 2011 18:07
Quake, Quake 2 and Heretic 2 don't run after update to Mediator TX Turrican(AEB) support.Games 14 25 August 2008 22:11
Workshop Pron Boot_WB Hardware pics 19 06 June 2008 21:02

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 19:01.


Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Page generated in 0.21219 seconds with 13 queries