Ship Viewer (BINARY!)

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Andrew Davie

Glorious...  this is a "ship test viewer" that lets you cycle between the installed 3D objects (joystick button press) and zoom in/out (joystick up/down).  This is using a newly-rewritten rendering pipeline that works on a poly/face level rather than an object level, giving finer granularity in timing. So, things can now get full-screen (although not fully-tuned so expect an occasional crash)...



Andrew Davie

Latest ship viewer binary. A couple of extra ships added.
+ use left/right to select a new palette (random)


Andrew Davie

#2
Newest ship viewer binary. Nearly all the Elite ships now present. 29 in total.
fire to cycle to next ship
up/down to move ship closer/farther
left/right to change palette

I ended up automating pretty much all of the conversion process, so the last 10 or so ships were very quickly installed. I should have automated much earlier.


Crossbow

I will need to give this a test when I can. The one Elite binary that I did have (Same one shown on ZPH I think), would crash as soon as the ship exploded. Both my main 7800 and a vader 2600 would doing this so it wasn't just my 7800. But again, I will need to give this a go and see how it behaves as it looks really awesome!


Andrew Davie

#4
Here I've done a lot of optimisation on the 3D engine - and despite this binary looking similar to previous ones (just a ship viewer), it is running much faster; particularly the triangle draw. It's a real challenge to get any speed in the systems - rendering thousands of pixels per frame (for e.g., a ship up close is rendering around 15K pixels) is time consuming and difficult to do in the overblank area. Very difficult.

So I'm at a bit of a "take a break" phase, thinking about future options. Maybe wait for a dual core alternative hardware option, or possibly try to get interrupts working and have the screen draw interrupt the rendering code. But that may not be as attractive as I first thought, so probably dual-core is the best option. Dunno, we shall see.

Controls:  up/down = move closer/further from ship
left/right = rotation around y axis
button+up/down = rotation around x axis
button press/release with no direction = change ship

This should run on the latest Gopher and PlusCart versions.
Stella will soon have the ability to run it, too.

The attached binaries are different ICC resolutions (ICC1, ICC2, ICC3).  The ICC2 and ICC3 will run without significant slowdown, but ICC1 will probably lag when things are up really close.

Al_Nafuur

Quote from: Andrew Davie on 17 Aug 2024, 02:56 AMSo I'm at a bit of a "take a break" phase, thinking about future options. Maybe wait for a dual core alternative hardware option, or possibly try to get interrupts working and have the screen draw interrupt the rendering code. But that may not be as attractive as I first thought, so probably dual-core is the best option. Dunno, we shall see.
Maybe waiting for the the PlusCart/FujiNet device. They ported the PlusCart code to the RP2040 and it uses an ESP32 instead of an ESP8266. But it is still in an early stage:
https://forums.atariage.com/topic/359421-fujinet-for-atari-2600/?do=findComment&comment=5501950

Bomberman94

Quote from: Al_Nafuur on 17 Aug 2024, 12:17 PM
Quote from: Andrew Davie on 17 Aug 2024, 02:56 AMSo I'm at a bit of a "take a break" phase, thinking about future options. Maybe wait for a dual core alternative hardware option, or possibly try to get interrupts working and have the screen draw interrupt the rendering code. But that may not be as attractive as I first thought, so probably dual-core is the best option. Dunno, we shall see.
Maybe waiting for the the PlusCart/FujiNet device. They ported the PlusCart code to the RP2040 and it uses an ESP32 instead of an ESP8266. But it is still in an early stage:
https://forums.atariage.com/topic/359421-fujinet-for-atari-2600/?do=findComment&comment=5501950


So, from an ,,end-user point of view" what is the benefit to have a Pico enhanced PlusCard? Is it ,,just" to have more power to do more network wizardry or other things? Can the existing PlusCard be upgraded or do i need another PlusCard (let's say the PlusCard P)?

Al_Nafuur

Quote from: Bomberman94 on 17 Aug 2024, 07:15 PM
Quote from: Al_Nafuur on 17 Aug 2024, 12:17 PM
Quote from: Andrew Davie on 17 Aug 2024, 02:56 AMSo I'm at a bit of a "take a break" phase, thinking about future options. Maybe wait for a dual core alternative hardware option, or possibly try to get interrupts working and have the screen draw interrupt the rendering code. But that may not be as attractive as I first thought, so probably dual-core is the best option. Dunno, we shall see.
Maybe waiting for the the PlusCart/FujiNet device. They ported the PlusCart code to the RP2040 and it uses an ESP32 instead of an ESP8266. But it is still in an early stage:
https://forums.atariage.com/topic/359421-fujinet-for-atari-2600/?do=findComment&comment=5501950


So, from an ,,end-user point of view" what is the benefit to have a Pico enhanced PlusCard? Is it ,,just" to have more power to do more network wizardry or other things? Can the existing PlusCard be upgraded or do i need another PlusCard (let's say the PlusCard P)?
I can't tell if there will be any benefit for the end-user. The FujiNet devices support a lot a network protocols on the device, but I don't think this is an advantage on the 2600. It all depends on the developers using these protocols, the PlusCart only supports PlusROM functions, but the developers can use their internet backend as gateway to all other protocols/services they want/need.

Once the ELF format is fully supported on the FujiNet device the additional CPU power of the RP2040 (and maybe the ESP32) might be useful for project like this here.

DirtyHairy

There is an undefined symbol in your ELF binary, _Z9initPlaneb. This is mangled for "initPlane(bool)".

Bomberman94

The last files (elite_ICC1 ... 3) don't run on my light sixer via PlusCart - only black screen.

DirtyHairy

Quote from: Bomberman94 on 21 Aug 2024, 05:28 PMThe last files (elite_ICC1 ... 3) don't run on my light sixer via PlusCart - only black screen.

That's because of the undefined symbol.

Andrew Davie

Quote from: DirtyHairy on 21 Aug 2024, 06:30 PM
Quote from: Bomberman94 on 21 Aug 2024, 05:28 PMThe last files (elite_ICC1 ... 3) don't run on my light sixer via PlusCart - only black screen.

That's because of the undefined symbol.

TY both for the report. Unusual I didn't notice this via Gopher. I will investigate that later. Part of working with bleeding edge tools/systems. Meanwhile, here are fixed files that hopefully work!


JetSetIlly

Quote from: Andrew Davie on 21 Aug 2024, 08:12 PM
Quote from: DirtyHairy on 21 Aug 2024, 06:30 PM
Quote from: Bomberman94 on 21 Aug 2024, 05:28 PMThe last files (elite_ICC1 ... 3) don't run on my light sixer via PlusCart - only black screen.

That's because of the undefined symbol.

TY both for the report. Unusual I didn't notice this via Gopher. I will investigate that later. Part of working with bleeding edge tools/systems. Meanwhile, here are fixed files that hopefully work!



The function is never called so it shouldn't ever be an issue. I've adopted the policy of accepting binaries with undefined symbols and simply logging that they're there. For example:

ELF: using stub for _Z9initPlaneb (will cause memory fault when called)
ELF: relocate _Z9initPlaneb (200024ac) => 200131c1

If the ELF loader in the Plus/UnoCart fails on load with these types of binaries I suppose I should I should change the behaviour. I'm not convinced that's what the Plus/UnoCart should do though.
https://github.com/JetSetIlly/Gopher2600
@JetSetIlly@mastodon.gamedev.place
@jetsetilly.bsky.social

DirtyHairy

I very much think that the Uno should reject binaries that cannot be fully relocated. To me, this is a matter of validation --- it is much better to have a deterministic error on load instead of memory corruption at runtime.

JetSetIlly

Quote from: DirtyHairy on 21 Aug 2024, 11:29 PMI very much think that the Uno should reject binaries that cannot be fully relocated. To me, this is a matter of validation --- it is much better to have a deterministic error on load instead of memory corruption at runtime.

Those aren't the only options. I think it's acceptable for the loader to link any unresolvable function to a handler function.  In the case of the hardware implementation, this might just be a BX instruction back to the calling location and/or forcing the program to exit back to the Plus/UnoCart menu.

In any case, the firmware would surely be improved if it could display error messages and a way of indicating why a failure has occurred.

https://github.com/JetSetIlly/Gopher2600
@JetSetIlly@mastodon.gamedev.place
@jetsetilly.bsky.social