phoboz

I guess it was because the developers were fully focused on the Jaguar, and not to make portable code that should work on any platform. I would love to see Descent using that engine:

Question is how much it is re-writing as compared to starting from scratch? If it's not only C code, but if it's code using floating point variables? This is something that needs to be emulated (very slow) even if run on the GPU. E.g. the Jaguar does not have a FPU (Floating Point Unit), nor did the PSX, nor did any other non-high-performace-computing-system at that time (with the exception of systems equipped with the Motorola 68881/2, 486DX, or Pentium II processors) So in that case it's not only about re-writing some code in assembler, but to completely redo the math. Unfortunately every code example for 3D today uses floating point variables, even many code examples for 2D games does, because everyone programs on PC these days. The most useful code examples I find are usually for the Arduino, for example the ATmega 3D engine.

The decision was purely based on artistic expression. From a technical perspective, Asteroite uses the same engine, it has 2 parallax layers and long musical scores. I think this is somewhat a little bit of a problem with the Jaguar (you know the whole 64-bit thing), that every game must show off the full capacity of the system, all the time. I know to many it is all about showing how much you can squeeze out of an old system. To me, it's that I found a good (open) platform powerfull enogh to realize my game ideas. That's why I eventually had to move away from the Vectrex. Nintendo rejected me as a developer for the Switch, so there you have it...

If you ask me as a musician? https://m.soundcloud.com/alexander-von-knorring

Yes, I think everyone can decide for themselves. If some think that percussions is not music, then it's just sound for them. I won't interfere with that. Personally I really don't see why this defintion is so important for the experience, if you percive it as music, or not. @jgkspsx better to call it soundtrack then for next poll?

No it's not. It's a tutorial on how to get started making a roguelike game. I based my initial research prototypes on it (that is the purpose of it), amongst other examples on the Internet, just to learn. In the end I made my own engine, as I deviated to much from the formula of any of these examples.

The cathegory was about how original the music was, not about how much music the game had. I opted for using music and abient sound in this game to enhance the experience of what happens in the game. If I would have had a playlist of constant synth beats running all the time in this type of game, there would be no way that I could have enhanced the felling of WAR when the monsters arrive... Different types of music, the ammount of music, and sound effects can be different depending on the game type. I belive the case is not always: "The more, the better", but this is just my opinion.

Yes you contributed both with graphics, and playtesting of Kings of Edom. Besides from that you also hatched additional ideas that contributed posetively to the gameplay, such as breakable objects. So you can feel proud of being part of the #1 release for the Atari Jaguar in 2021.

None of these sub categories covered things as gameplay, controls, replay value, and overall enjoyment, so that might be part of the explanation. Nevertheless congratulations to @CyranoJ, @agradeneu and @Albert for winning in the presentation categories.

Rapax is the name of that beast, the artist is @Eternal-Krauser.

@ZeroPage Homebrew there is a new release trailer for Asteroite:

New trailer by @Eternal-Krauser

The design was very innovative from a technological perspective. 5 processor system with a shared bus. 2 custom RISC cores, as opposed to the path every SoC designer takes today, e.g. to get licensed ARM, or MIPS cores in there. The problem is that there wasn't enough effort, nor prestige in the software development area. I heard (rumors) that a software developer had the same status as a person who assembles a cartridge (e.g. they are both into assembly ?)

When I act on feedback from testers, I usually feel that the game gets way to easy. When you are developing a game you get really good at playing it, because you need to in order to check the features you implemented (over and over again until it works) As a developer it is usually a good idea to back down a little bit on the difficulty, because no other person is ready to spend the same ammount of time on the game as the developer(s).

I like this a lot, the Jaguar definately need more platformers. Kind of reminds me about Hollow Knight. Keep up the good work @CyranoJ and @agradeneu

When using a larger EEPROM will the default (128 bytes) driver work for it? (as it is a serial EEPROM, e.g. there are no additional address lines to consider as for a paralell addressing interface) For example the driver I use have 2 functions: void eewrite(uint16_t address, uint16_t data); uint16_t eeread(uint16_t address); With the default 128 byte ship (which is actually 64 16-bit words) I can send an address up to 63. If I use a larger chip (of 2 kilobytes). Does this mean that I can give addresses up to 1023 without making any changes to the actual driver code? I am talking about a switch to the 93C86 chip here. Do the emulators also emulate the larger EEPROM chips properly? PS. It was quite a challange to squeeze all data for the 3 save slots of Asteroite into the default 128 byte chip. So I think I need to expand for future games.

None of the games for the N64 was 64-bit, and Nintendo even had the "64" in the name of the console. Technically the MIPS CPU of the N64 could run 64-bit programs, but none of the games for the N64 used that mode. Question if it would even be compatible with the rest of the hardware in the N64? Besides from that, the only effect of having a 64-bit program for the N64 is that the program would be twice as large. Given that the N64 used cartridges, it would just mean that cartridges would be more expensive to produce. The only benefit of running in 64-bit mode on a MIPS CPU is that you can have larger precision calculations, but this is not something that 3D games may benefit much from. You may also address a larger memory space, but that is neither a benefit given the limited size of the cartridges, and limited ammount of RAM in the system. On the Jaguar the 64-bit is used for shuffeling graphics with a higher bandwidth, which is something that is beneficial in games. On the other hand, you have so many sub-systems sharing the same bus, so it is no so easy to get the full benefit of that.

Having worked with this renderer for a while now, I noticed the same trend. After I added a cockpit image in front of the 3D rendering area, it became even less stable. I am wondering if it is the display list creation routines in olist.c that are causing the problems? - What about the alignment of the display list objects? Are they always aligned properly to a .phrase boundary when using this module? I also note that the -ii flag is given to the linker for the textures, but the option -i align the data to the .phrase boundary. - Don't the image data (textures etc.) need to be aligned to a .phrase boundary? (or at least aligned to a .long boundary) I tried to gradually remove all the code that has to do with the renderer (only clearing the screen so I could know if there was any color output), but I still got the blank screen 1 out if 10 times practically without any code related to the renderer, so my suspicion is really now that the problem has to do with the way the display lists are created (e.g. the module olist.c, under the lib directory)

I should really change this part of the implementation before even attempting to do that. (E.g. to avoid reloading the whole renderer for every model) The first game is going to be an arcade like dogfight game, so probably there won't be a need to render more than one ship on the screen at the same time. That's how they did it for the Spacewar 2000 prototype. Everything else you see on the screen (besides from the ship you are fighting) are scaled sprites, or normal sprites in that prototype. I'd rather start by making something fun using this engine, than spend my whole life to make this the most generic 3D engine in the world ?

You have to ask @Eternal-Krauser about that. Changes are being made to the models, as well as to the textures. I guess one obvious optimization is to get rid of unneeded polygons (e.g. overly smooth surfaces that look smooth anyway due to gouraud-shading)? As I mentioned before, large textured surfaces close to the screen degrades the performance notably. So the fill speed seems to be a bottleneck.

The 3D models were optimized, and the size of the rendering area was reduced from 320x200, to 320x160. It was done because the cockpit will cover 40 pixels at the bottom of the screen, and there is no point in rendering stuff there that won't be seen.

I have not attacked the renderer so much yet, rather I am in the process of understanding it, and how to use it in the most efficient way. There are room for optimizations depending of what type of game to make. This code is quite different from using the Removers' library, which is really optimized for 2D. Now I have to learn some things from scratch again (e.g. really learning about some of the low level aspects of the Jaguar, which was hidden by the abstraction layer that the Removers' library provided) I think that this is the long path that a Jaguar developer has to take in order to not have a game requiring 2 seconds to render a frame (using the 68k to draw pixels into framebuffer)

Probably not, as this would be the work for the Object Processor. Not for the GPU and the BLiTTeR.

I haven't really tried to push more than ~200 polygons, but it stays at 25 FPS in that case. Turning off texturemapping (using gouraud shaded polys only), makes it stay at 50 FPS. We haven't considered using more detailed models than this. As this will be a one-on-one dogfight game, we focus on making the ship models look nice with textures and so on. Note that I belive a game engine is best evolving in a sharp projects. So if the need arise to optimize further, add new features etc. that will happen over time. I think that Jeff Minter said that a "game is a living thing".

You can see the FPS at the top left of the screen (you probably have to maximize the video window, unless you have very sharp eyes). I have a PAL system, so it alternates between 50, and 25 FPS. On an NTSC system that will probably be between 60, and 30 FPS. Removing the debug text actually makes it better, but there will be other calculations done in the final game as well. It seems like a feasable target to set, that we should reach double digit framerate in the end. It's not the number of polygons that matters the most for performance, but rather it's the size of the polygons. So it's probably the BLiTTeR that is the bottleneck (e.g. due to texturemapping)