Fast 3D graphics for SPECCY, is it really possible? Perhaps the following article will reveal previously unknown capabilities of SPECCY for you and prove useful when working with three-dimensional objects. The article is aimed at more or less prepared readers, but it may also be useful even for beginner users...
Despite some chaotic and incomplete presentation of information, it describes to some extent an outstanding method of working with 3D objects in real time. The procedure is remarkable in that it works very quickly. The essence of this method is that not each point is rotated individually, but an entire plane at once. This method can be useful not only for creating cool vector effects but also for writing new games. And how rulez'ly old vector games will look when redesigned with the latest coding achievements! For example, ELITE, running 2-3 times faster or smoother!
Let's move on to the material provided by RUFF before he tasted the thrill of writing games on the Amiga and became successful at "coding" there... A good example illustrating the algorithm described below is the effect from the demo "Hallutinations in Opera" — a rotating 3-D man made entirely of vectors.
Once, I read an article in "ECHO 1" about displaying 3-D objects. It described the traditional method that everyone (who knows) uses. It is, of course, very interesting to rotate points around the X, Y, and Z axes using special formulas.
For rotation around the X axis:
Y' = COS(N) * Y - SIN(N) * Z
Z' = SIN(N) * Y + COS(N) * Z
Around the Y axis:
X' = SIN(N) * Z + COS(N) * X
Z' = COS(N) * Z - SIN(N) * X
Around the Z axis:
X' = COS(N) * X - SIN(N) * Y
Y' = SIN(N) * X + COS(N) * Y
(N - angle of rotation)
This method has its drawbacks. More precisely, one very significant drawback — it takes a lot of time! The multiplication operations (no matter how fast they are) and the calculations of COS and SIN (even using a table) take a considerable amount of time. Considering the sign problems and the fact that objects are usually rotated around all three axes at once (some even use the BASIC calculator), there’s no choice but to first calculate the coordinates and then output the graphics. Some even load pre-calculated coordinates from BASIC separately. This is lamer! (Except in certain cases). However, sometimes there are programs with REAL-TIME 3D CALCULATING. But how they lag!!!
...That was the introduction. Now, closer to the point. I have come up with a new method for displaying 3D objects. Here are its advantages:
- It is much (!!!) faster than the above method. To calculate the coordinates of a single point takes approximately 200 cycles (if desired, it can be made even faster).
- A 3D object can not only be rotated but also deformed (stretched, compressed, etc.).
I cannot provide the entire listing of this effect here, so I will give it in pieces that you will collect and supplement as needed.
Here’s the first fragment — the procedure for printing a 3D object:
PRINT:
LD (SAV+1),SP ; save SP
LD SP,...
; ... - This is the starting address of the coordinates of the 3D object's points. Each point takes 4 bytes (3 bytes - coordinates X, Y, Z; 1 byte - high byte of the axis table (more about it later). By the way, it is later denoted by the label TABAX).
EXX
LD HL,BUFER ; Special buffer for clearing the screen
; (see below)
LD B,175 ; number of vector points
LP1
; Next comes the procedure for printing a single point:
EXX
POP BC ; in BC - Y,X
POP HL ; in HL - high byte of the axis table, Z
LD A,(HL)
LD E,L
LD L,B
INC H
ADD A,(HL)
INC H
LD L,C
ADD A,(HL)
ADD A,HX
LD C,A
INC H
LD A,(HL)
LD L,E
INC H
ADD A,(HL)
LD L,B
INC H
ADD A,(HL)
ADD A,LX
LD L,A
; Now the coordinates of the points (X and Y on the screen) are calculated and placed in registers C and L. Next comes the procedure for printing the point at the coordinates in these registers (69 cycles). For this, a special table is needed; those who do not know this procedure can use their own.
PLOT:
LD H,TABLE_P
LD D,(HL)
INC H
LD A,(HL)
INC H
LD L,C
ADD A,(HL)
INC H
LD E,A
LD A,(DE)
OR (HL)
LD (DE),A
; Well, that's it. The point has been printed, now you can (if you want) place the address of this point on the screen in a special buffer (so that you can quickly clear the screen later using the method POP HL: LD (HL),0: POP HL: LD (HL),0: POP HL...).
LD A,D
EXX
DEC HL ; The address of the buffer grows upside down (for convenience).
LD (HL),A
EXX
LD A,E
EXX
DEC HL
LD (HL),A
DJNZ LP1 ; Next point.
SAV LD SP,0
RET
Somewhat unusual commands LD SP,0 : RET, but it saves memory.
I hope you guessed that this procedure by itself will not give anything. YOU STILL need to write a screen clearing procedure and a procedure for creating axis tables. I do not provide them here due to their larger size (length). I could have written the screen clearing procedure, but regarding this, everyone has their own principles (some would write an installer, some would place everything in DUPs, etc. and so on). In short, write it yourself. As for creating tables with axis coordinates, I’d better first explain the principle.
Y ===== ....
________________ === == . .
/!^ ! == . .
/ !* ! === . .
/ !>48 ! === . .
/ !* ! === . .
! !* .A ! == . .
! !* ! === == . .
! !* ! ===== ....
! !* !
! !* ! picture 1
! !* !
! !* 32 !
! _______^________!
! 30/****************>/ X
! ^/* /
! /* /
!/<________________/
Look at PICTURE 1. As you guessed, this is a cube. Imagine that inside it is a 3-D object. Each point of this object has three coordinates along the Y, X, and Z axes. Here the axes are not infinite. For example, they can consist of 64 points (coordinates). That is, a point can be defined by three numbers from 0 to 63. And now the most interesting part...
Take, for example, point A with coordinates Y=48, X=32, Z=30. How to find its coordinates on the screen, considering that the Z axis is rotated as shown in the picture? Each axis has a point marked with the corresponding coordinate. The main thing is to find the coordinates Y and X of these points and the center (the intersection point of the axes) on the screen. Let’s say we know them:
Coordinates from the top left corner Y,X:
On the Y axis - 70,46
On the X axis - 172,140
On the Z axis - 180,40
Center - 172,46
To calculate the screen coordinates of point "A", we apply two simple formulas:
Let’s denote the screen coordinates (the same as above, just replacing numbers with letters):
On the Y axis - Yy, Xy
On the X axis - Yx, Xx
On the Z axis - Yz, Xz
Center - Yc, Xc
So, the formulas are:
Y = (Yy - Yc) + (Yx - Yc) + (Yz - Yc) + Yc
X = (Xy - Xc) + (Xx - Xc) + (Xz - Xc) + Xc
Substituting the values:
Y = (70 - 172) + (172 - 172) + (180 - 172) + 172 = 78
X = (46 - 46) + (140 - 46) + (40 - 46) + 46 = 134
Coordinates of point "A" on the screen are 78,134.
The above printing program for the 3D object did just that — calculated the sum (though a bit differently), printed the point, and remembered the address on the screen. And what should the axis coordinate calculating program do? — Of course, calculate the axis coordinates... But let’s first sort out the formulas... You’ve probably been expanding brackets for a long time, canceling unnecessary center coordinates and are confident that I didn’t notice? You can do that, but it makes little sense.
Here’s the thing: from each coordinate of the point, the axis coordinate is subtracted. Let’s return to the coordinates of the axis points. As you guessed, we will have to calculate the coordinates of all 64 axis points. And these coordinates will not be calculated as they are on the screen, but with the center having coordinates on the screen 0,0. Then we just need to add the center coordinates.
The procedure for calculating the axis coordinates takes little time. For example, in my case (if the procedure is placed at the beginning of the interrupt), the frame scan does not even reach the first lines of the screen. But for the axis coordinates, a buffer is needed. Let’s calculate its length: one axis - 64 points, which means 128 coordinates. There are 3 axes in total, so the total number of coordinates is 128 * 3 = 384 coordinates. One coordinate - one byte. But to speed up the output of the 3D sprite, it’s better to store the coordinates of one axis in 512 bytes (Y coordinates - 256 bytes, X coordinates - 256 bytes. Out of 256 bytes, only 64 are used). In total, the buffer will be 512 * 3 = 1536 bytes. Not too much either.
Now, here’s the program itself. The principle of operation will be explained along the way. As mentioned above, we will calculate the coordinates of the axes as if the center had coordinates 0;0. Then, during the output, we will add the center coordinates. This will save time. By the way, the center coordinates in my program will be stored in the register pair IX, so do not change its content, or save it and then restore it (my axis coordinate calculating program is linked to the 3D sprite printing program via the IX pair and the contents of the axis coordinate buffer).
AX
; Procedure for calculating axis coordinates. The coordinates (on the screen) of the extreme points of the axes are specified in registers HL', BC, HL. The center coordinates in DE. By the way, for those who do not want the 3D object to compress and stretch, they can use the 3-D rotation formulas for rotating these 4 points (look up).
TABAX EQU 250 (64000 = 250 * 256)
; High byte of the buffer where the axis coordinates are calculated. The address of the buffer is a multiple of 256 (!!!)
LD A,E
SUB 32
LD E,A
LD A,L
SUB 32
LD L,A
LD A,C
SUB 32
LD C,A
EXX
LD A,L
SUB 32
LD L,A
EXX
LD HX,D ; Refers to the high byte IX,
LD LX,E ; low byte IX.
; (Undocumented Z-80 processor commands. 6 cycles)
LD A,L
PUSH AF
LD A,C
PUSH AF
EXX
LD A,L
PUSH AF
EXX
LD A,H
PUSH AF
LD A,B
PUSH AF
EXX
LD A,TABAX
LD (VAR),A
LD A,H
LD B,HX
CALL K64
POP AF
LD B,HX
CALL K64
POP AF
LD B,HX
CALL K64
POP AF
LD B,LX
CALL K64
POP AF
LD B,LX
CALL K64
POP AF
LD B,LX
CALL K64
RET
K64
; K64 - the most important procedure. Called by the program a total of 6 times. Calculates the intermediate 64 coordinates. The target coordinate is in register A, and the source in B. The source is our center, so in B, the center coordinate (Y or X) is always. In general, it is only needed to get the difference (A - B or B - A) and to determine the direction (positive or negative). Since the coordinates of the center are 0;0 - the address of the table in 64 bytes (where to place all the numbers) is a multiple of 256. Its high byte is set by the address VAR. This byte, by the way, the program itself increases by 1 at the end. Thus, I calculated the Y coordinates first, calling this procedure, and then the X ones, calling it again. We have three axes, so the K64 procedure is called 6 times.
CP B
JP C,LOOP1
SUB B
LD L,A
LD H,0
ADD HL,HL
ADD HL,HL
EX DE,HL
LD HL,0
LOOP2
EXX
LD A,(VAR)
LD H,A
INC A
LD (VAR),A
LD L,0
EXX
DUP 64 ; or some kind of cycle, like
; LD B,64:...:DJNZ ...
LD A,H
ADD HL,DE
EXX
LD (HL),A
INC L
EXX
EDUP
RET
LOOP1
LD C,A
LD A,B
SUB C
LD L,A
LD H,0
ADD HL,HL
ADD HL,HL
EX DE,HL
LD HL,0
LOOP3
EXX
LD A,(VAR)
LD H,A
INC A
LD (VAR),A
LD L,0
EXX
DUP 64 ; or some kind of cycle, like
; LD B,64:...:DJNZ ...
SBC HL,DE
LD A,H
EXX
LD (HL),A
INC L
EXX
EDUP
RET
CP B
JP C,LOOP4
SUB B
LD L,A
LD H,0
ADD HL,HL
ADD HL,HL
EX DE,HL
LD H,B
LD L,0
JP LOOP2
LOOP4
LD C,A
LD A,B
SUB C
LD L,A
LD H,0
ADD HL,HL
ADD HL,HL
EX DE,HL
ADD A,C
LD H,A
LD L,0
JP LOOP3
VAR
NOP
NOP
Well, that’s all... For those who did not delve into all the nuances, or do not want to additionally change or improve this method, but want to write everything in their own way, some recommendations:
1. Do not forget about the format of storing the coordinates of the 3D object. Do not forget about buffers (axis coordinates, delete buffer).
2. Calculate the coordinates of the extreme points of the axes (Kz, Kx, Ky, and center) using rotation formulas or a sinusoidal table.
3. The algorithm of the output program should be somewhat like this:
EI
HALT
DI
CALL PRINT
Insert into HL', BC, HL, DE the following values from the sin. table (you also need to consider that they should not be too large, otherwise the sprite may go off the screen and come back from the other side).
CALL AX
Clearing the screen using the DELETE buffer.
It is advisable to adapt everything for working with two screens.
JP BEGIN
Contents of the publication: Rush #01
- AMIGA NEWS
Amiga Inc works on Amiga OS 3.5 with enhancements like CD drive and PowerPC support. Split development for M68K and PPC processors. Delayed release to late 1999 or early 2000.
- AMIGA NEWS
Description of the 'Fast JPEG 1.10' viewer for Amiga, focusing on its features, installation, and usage. It highlights advantages like fast processing without quality loss and provides user tips. Readers are encouraged to share their software experiences.
- AMIGA NEWS
Basic programming for classic Amiga, discussing challenges and sharing knowledge in Amiga coding. Overview of Amiga graphics capabilities and processor features. Introduction to Amiga assembly language specifics.
- AMIGA NEWS
Overview of events related to the Amiga platform from early to mid-1998. Highlights include new hardware, software releases, and notable company collaborations. Future updates and developments are scheduled for the next issue.
- AMIGA NEWS
Collection of cheats and secrets for classic Amiga games compiled by Postcard Man. Readers encouraged to share their findings on complex games. Selection of tips and level codes provided for various games.
- AMIGA NEWS
Discussion of Phase-5's graphics cards and Permedia 2 processor capabilities. Details on Permedia 2's 2D/3D acceleration and compatibility. Mention of GLINT Delta processors and comparison of prices and availability.
- AMIGA NEWS
Analysis of Amiga's survival in the 90s, highlighting community efforts and technological advancements. Discussion on hardware improvements and software development. Encouragement for further exploration and learning about the Amiga platform.
- Spectrum Programming
Explanation of a fast method for real-time 3D graphics on the ZX Spectrum. Introduces efficient rotation and deformation techniques for 3D objects. Emphasizes improvements over traditional methods with practical examples.
- Spectrum Programming - Ticklish Jim
Discussion of combining sound effects with music for Spectrum's AY chip. Examples from development of 'CSC: Deja Vu' and technical challenges faced. Contains practical guide and code examples.
- Spectrum Programming
Discussion on byte mirroring and background restoration in ZX Spectrum programming, with examples.
- Spectrum Programming
Comprehensive guide for system programmers with practical tips for creating efficient and user-friendly software, including coding techniques, device compatibility, and program testing strategies.
- Spectrum Programming
Advanced coding techniques and modern graphics methods for ZX Spectrum. Tips for optimizing graphical procedures and coding on assembly. Useful advice for programmers to improve performance and efficiency.
- The End
Reflections on the creation of the first issue of the magazine 'Rush', its goals, audience, and future development.
- ZX-SOFT - Вячеслав Медноногов
Development updates on Vyacheslav Mednoy's new game 'Black Raven II', including gameplay changes, new spell introductions, and performance improvements.
- ZX-SOFT
Overview of new features in the updated commander from REAL software for ZX Spectrum, including file management, autodetection, and media viewing. Improvements in text, font, and music handling. Questions addressed regarding future updates.
- ZX-SOFT
Debate on which demo deserved the top spot at Funtop'98: Forever by DR or Refresh by XTM. Discussions in the demoscene community highlight the clash between technical prowess and conceptual depth. Different opinions reflect on the evolution of demoscene preferences.
- Authors
Acknowledgment of contributors and partners in creating Rush magazine. Detailed roles of each author and collaboration insights. Recognition of technical support and media partnerships.
- Virtual Specky
Discussion on converting graphics from PC to Spectrum, featuring insights from various experts. Techniques for improving conversion quality and tools like Photoshop are detailed. Emphasis on post-conversion refinement in Spectrum graphics editors.
- Virtual Speccy
Discussion on the CBSpeccy emulator for ZX-Spectrum on Amiga, highlighting its features, community opinions, and technical performance. Criticisms and praises for its emulation capabilities, particularly compared to PC emulators. Examination of potential improvements and community debates around version updates.
- Virtual Speccy
FAQ on ZX-Spectrum emulation on PC, covering popular emulators and file formats. Instructions for using different emulators and managing file types like Hobeta and TR-DOS. Discussion on Russian ZX-oriented servers and resources for enthusiasts.
- Introduction
Introduction to the Rush magazine, emphasizing creativity, progressive scene, and the goal to create a superior information source. The magazine seeks to gather promising groups and offer a unique perspective. Focuses on content and atmosphere, welcoming creators to contribute.
- Introduction - Grunge
Introduction to Rush, a new scenemag for Speccy/Amiga enthusiasts, aims to provide quality content and news while encouraging reader feedback.
- Interview - Konex
Interview with ANTARES group after FUNTOP-98. Discussion on their demos, challenges, and future plans. Insight into the group's formation and dynamics.
- Interview - Kvazar, DUX
Interview with Alexander Seleznev (KVAZAR), discussing his history with computers, the state of the ZX Spectrum scene, and future plans.
- Interview - Kvazar
Interview with Vitebsk group POWER on demo 'Crazy Love', development experiences, and future projects.
- Informatorium
Exploration of a CD with emulators for various platforms, highlighting Spectrum. Details the content organization and diversity. Concludes with insights from the CD-ROM Project's Spectrum software collection.
- Informacrium
Compilation of interesting and useful Internet addresses related to Amiga resources, including magazines, hardware manufacturers, and software companies.
- Informacrium - Viator
Overview of existing and upcoming publications on the Amiga platform. Discussion of the availability and distribution challenges for Amiga literature. Appeal for collaboration with new publications.
- About the Magazine
Discussion on creating a multi-platform magazine focusing on Spectrum, Amiga, and PC. Emphasis on broader understanding of computer scene. Encourage professionalism and adaptation to changing technology.
- Parallel Worlds
Overview of the evolution of Windows OS and PC processors from 1981 to 2000. Development milestones of MS-DOS, Windows, Intel processors, and competition with AMD and Cyrix. Challenges in maintaining compatibility with new processor technologies.
- Parallel Worlds
Overview of Macintosh models and their relevance in design and graphics fields, covering prices and specifications from 1997-1998. Discussion includes the evolution of Apple's hardware, notably the PowerMac series, and compares new G3 processors with PC counterparts. It highlights the resurgence of Macintosh post-crisis and its ongoing influence in the market.
- Development of the Spectrum - Slider
The article discusses a new graphical extension for the ZX Spectrum that enhances color palettes without increasing resource demands. By using a modified flash signal, new colors are created without interfering with existing software compatibility. The article provides implementation details and addresses practical usage concerns.
- Development of Spectrum
Connecting a CDOS modem to the 'Compact-128' computer by addressing keyboard port conflicts. Description of hardware modifications to solve the issue. Solution includes automatic blocking using a transistor inverter.
- Development of Spectrum - Ars
Discussion on AZX-Monstrum 512K development, its hardware compatibility, processor options, and potential enhancements in graphics and OS.
- Development of SPECTRUM
Discussion of Clive Sinclair's new computer platform, the ZX2000, designed to outperform PCs with enhanced speed, affordability, and battery efficiency.
- Development of Spectrum - Андрей Савичев
Examination of the evolution and ongoing relevance of the Z80 processor, and its role in embedded systems. Comparison of Z80 with its successors, highlighting advantages like energy efficiency and command enhancements. Overview of integrated Z80-based CPUs and their peripherals.
- Advertisement
This article is an advertisement for Scorpion products including hardware for ZX Spectrum and Amiga software, along with pricing and ordering details.
- Advertising
Collection of advertisements for Amiga and ZX Spectrum hardware and software, with contact information for sellers and details about the new Amiga magazine subscription.
- Advertisement
Advertisement for X-TRADE's General Sound music board. Includes pricing, technical details, and purchase instructions. Features a FAQ section and compatibility info.
- Meaning Without Meaning - Viator
Philosophical reflections on existentialism, immortality, and human destiny. The narrative weaves through stories of ambition, the quest for eternal life, and a utopian downfall. A blend of introspection and speculative fiction.
- Scene vs Professionals
Exploration of the demoscene's creativity versus commercial game development. Discussion of potential for professional-quality programs by scene members. Call for collaboration with leading scene groups.
- Scene Chronicle - Андрей Савичев
Reflections on ZX Spectrum's enduring appeal, its community's resilience, and its potential resurgence in Russia.
- Scene Chronology
Overview of the Rush group's activities, including past projects, current endeavors, and future plans, with emphasis on software development and gaming.
- Scene Chronicles
The article discusses various ZX Spectrum scene news, including game releases, demoparties, and updates from developers and teams.
- Chronicles of the Scene
The article discusses the FUNTOP'98 international computer art festival held in Moscow, highlighting key events, notable attendees, and the various competitions held during the event.
- Scene Chronia
Discussion on Amiga scene development through collaboration, addressing user isolation and promoting network expansion.
- Shell Management
Статья описывает управление оболочкой для ZX Spectrum и Amiga, включая клавиши и функции для навигации. Упоминаются особенности работы на Amiga с PAL монитором и предоставляется контакт для поддержки. Также отмечено, что текстовые файлы имеют стандартную MS-DOS кодировку.
