rensoup
-
Posts
1,903 -
Joined
-
Last visited
-
Days Won
5
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Posts posted by rensoup
-
-
4 hours ago, chm said:
Hi guys,
Just wanted to share an idea I got.
Playing around with generic frame interpolation ai model I made short flick from IK.
The model is general purpose and I put extremally low effort using it, just to see what will happen.
Result is really cool and putting more effort it could probably be much much better.
Is it even remotely viable to add some extra animation frames to the game?
Very cool!
Can you share details on the process ?
5 hours ago, chm said:From what I understand there is no source code or reverse engineered version of this cool game so it is probably out of the question, but still wanted to share and ask if this is something worth pursuing
I believe you want to talk to @mrr19121970, I think he was involved in the C64 version of IK ultimate:
On 11/20/2017 at 3:24 PM, mrr19121970 said:Sorry to dig up this old thread. Doing something similar on the C64:
I wonder if anyone is up for porting to the ATARI too ?
https://www.lemon64.com/forum/viewtopic.php?t=67078
34 minutes ago, _The Doctor__ said:realize it's a tool for making smoother video recordings but not a change for the Atari itself.
But like he said the frames can be extracted from the video and put back into the game!
-
1
-
-
Depends what your target is... Are you going to use extra RAM or ROM? 50/60fps ?
With extra RAM/ROM you would be able to do many more optimizations.
Mode 4/E are the only candidates with you want to maintain the original resolution. Both are 160x200 x4colors but mode4 gives you that limited 5th color at the cost of being more difficult/slower to use especially if want to mix software sprites with hardware ones which you're going to have to by the look of it.
-
2
-
-
21 hours ago, tatqoo said:
Hi everyone. Another mod ported to Atari.
Love matkamies!
Still enjoying Still alive!
-
13 hours ago, Steril707 said:
And, what I really like with the Atari 8-Bitters, there really seems to be still some headroom to improve what currently is, and we can be a part of it...
Absolutely!
...then we can all disagree in which direction to go
-
2
-
-
10 hours ago, tatqoo said:
That is definitely ME
I believe the result above is tolerable and I can guarantee I am not going to create perfectly sounding ports if that means days of tweaking.
It's very very tolerable! Please post more for us to tolerate!
-
3
-
-
17 hours ago, Steril707 said:
Is there any possibility for this to run on Mac OS, since it's been done in C#?
Seems DearImGui is existing for Mac OS as well. How is that working with C#, if it was made for being used with C++.
I'm using Dimgui C# bindings done by this guy: https://github.com/mellinoe/ImGui.NET
for rendering I'm using his rendering library: https://github.com/mellinoe/veldrid
Veldrid is a cross-platform, graphics API-agnostic rendering and compute library for .NET. It provides a powerful, unified interface to a system's GPU and includes more advanced features than any other .NET library. Unlike other platform- or vendor-specific technologies, Veldrid can be used to create high-performance 3D applications that are truly portable.
So in theory, yes... with a caveat. I build from VS and it seems to produces all sorts of versions for linux,Win,... I've no idea if they actually work.
The caveat is that I'm using a sound library (the wave output, not the pokey emulation) that is not portable, but I could switch to something that is like SDL ?
If you're interested, perhaps you could try building the veldrid engine from github and see if it runs on MacOS as a first step ?
-
1
-
-
1 hour ago, tatqoo said:
If we consider that the first priority is to get many new MODs converted to Atari then pattern editing improvements can wait.
I wouldn't say it's top priority but it's one way to get music quickly to the A8 to demonstrate the potential. And you've produced so much cool stuff that it's definitely worth carrying on !
1 hour ago, tatqoo said:However, to make creating original tunes easier we definitely need copy/paste in tracks, copying instruments and copying song lines with transposition. But that's in future if I understood and it's fine for me.
I will start looking into those since things are a bit more stable.
1 hour ago, tatqoo said:I am having great fun converting new mods.
Awesome, I really enjoy listening to them!
-
14 hours ago, Steril707 said:
@rensoup: Can you give us here an overview what the current state of your tracker is?
It's functional and somewhat familiar to those who use RMT. It's probably rougher in terms of pattern editing but I don't really know since I don't use it myself (0 music skills). Instrument editing should be fine. It's still crashing a bit and has very few keyboard shortcuts so far.
Perhaps @tatqoo can tell you more about his user experience...
The player started as a C# version of the 6502 RMT player. On top of RMT, it's got a bunch of extensions like track effects. Those can be any effect that are worth implementing but right now I've added Amiga mod effects to demonstrate the possibilities so that means that mods can be converted more easily than with RMT... which doesn't mean it's easy, instruments still have to be done from scratch though.
Most Amiga effects are based on manipulating sample frequency and/or volume. I don't really know how sliding samples frequencies relates to sliding Pokey frequencies but it seems to work okayish. For volume, it should be closer even though the A8 has less precision.
Additionally, since track effects keep manipulating the frequencies until another note is played, it's not really possible to use RMT envelope commands (beyond the 1st step). So once the track effect converts the note to a frequency, it's not possible to go back to a note (I suppose?). But some stuff still works like instrument vibrato which can be combined with track effects.I've also added an extended Arpeggio effect based on a C64 tracker and suggested by Tatqoo, again as a demonstration. He also suggested adding the AHX amiga format because there seems to a good library of tunes for it. I suppose it uses track effects to so in theory it would be a matter of adding those effects to the existing MOD ones. (same could be done with FC13 FC14)
A lot of RMT limits have been removed like instrument count. You can have 256 instruments (it's any number in reality) which leads to extra features like easy instrument bank creation (you can load files as banks and easily copy instruments to your main module).
The benefit of not having a 6502 player but a C# one means that in theory any effect can be done, so it is possible to come up with effects that are specific to the A8, maybe easier PWM setup, effects that are compatible with instruments envelopes... again I don't really know due to my music skills.
DearImgui turned out to be a great GUI too so it's quite easy to add widgets for new features ( especially combined with C# ).
The file format is text so it's easier to debug/fix and output format for the A8 is LZSS so that's been working for ages (the player is used in both the tracker and RMT2LZSS)
-
5
-
1
-
-
6 minutes ago, tatqoo said:
Let me present the first tune created with DxRMT.
Where's that "tear of joy" emoji !
Thanks Tatqoo for sticking to it for about 20 beta releases or so... ( no release yet as he keeps asking for now features
)
-
1
-
2
-
-
18 hours ago, VinsCool said:
I said that related to the troubles going from rmt to rmt2lzss to export data, that was just troublesome on the long run, and resulted in sound that was not matching the sound of the tracker side, or required a lot of extra post production tweakings to get anything that was satisfying.
I'm honestly still kind of frustrated about the convoluted work around some tunes I made before, such as the prince of persia music, for example.
It's not about it being a competition... you're saying it's convoluted to convert a tune and its output can be inaccurate.
It converts a tune or more in a bunch of clicks and I spent a lot of time batch testing it against about 1000 RMT 1.28 tunes, and it's 100% accurate.
For PoP you used custom hacked extensions which it wasn't meant for and painful to use but for getting a 1.28 tune into a game/demo, it is convenient and accurate.If for my use, there was any advantage in outputting straight from RMT, I would use that.
-
2
-
-
3 hours ago, VinsCool said:
I've been quite busy working on exporting data at the moment, specifically LZSS, in order to make the process much easier in the future, to not waste any more time and energy using 3rd party programs such as RMT2LZSS, and have the ability to integrate the data with more ease.
Thanks for the cheapshot... RMT2LZSS does exactly as the title says with a button click, and integrating it with the example source is just a matter of renaming the file and assembling the code
-
1
-
-
I'd say you don't because RMT tends to be a CPU hog but that's not always true... LZSS is the alternative but it can take more memory but that's not always true either...
-
2
-
1
-
-
I'm not a fan of mode4 usually, but it really comes down to how useful the 5th color would be in this case. And there's also potential for saving some space with it, which I'm guessing would be needed for software sprites.
Online version for the curious https://impossible-mission.krissz.hu/
-
1
-
-
On 1/7/2023 at 11:26 AM, miker said:
I found something like this: https://github.com/acapitani/im
I randomly browsed through the code, it doesn't look like it's suited for 8bit. Vector math is all over the shop... So I'd agree that the P4 source may be the best bet.
-
4
-
-
Supposedly the oric version isn't as good though... I haven't played it, just some comment I read.
Even without the source I doubt the biggest hurdle is the limited charset, I don't see what prevents the use of multi charsets.
-
3
-
-
15 hours ago, Heaven/TQA said:
Well… that was my intention in the P4 new port… regarding available experience and source.
those Oric and BBC ports help maybe to get things done as those machines have less RAM and simpler architecture as for Oric the highres bitmap is at a000-bfff e.g.
Assuming the P4 author is willing to pass it, then yeah it'd be a better start than the Oric or BBC without source. Pretty unbelievable that it's available on Oric too
Also never noticed that the main sprite on C64 is hires until now.
14 hours ago, MrFish said:@mrsid finished his Prince of Persia port right before the source code was released. Quite the learning experience on his part.
A multi year one indeed... and so much effort was spent on rebuilding the source which like you said was recovered right after! But I won't argue why people like to do certain things which seem pointless to others.
14 hours ago, MrFish said:One of the authors of the C64 -> 7800 conversion of Impossible Mission showed up some years back. He was able to resurrect the source, but wasn't willing to share it, unfortunately.
Interesting read! Too bad the author seems to lack the motivation... Perhaps it's time to ping him again.
-
this one looks interesting:
While it's always entertaining discussing ports, the amount of work is just humongous (even for a crap game...). For PoP, I had the commented source code, which made it less humongous a task.
Without the source, you need to figure out what the code does AND you need to produce a relocatable source so that blocs of data/code can be moved around. The amount of work required for that is likely to burn you out, if not completely at least enough to not make you not want to bother trying on making A8 specific improvements.
A good candidate for a port is a good game with commented and buildable source on the original platform... not many of those are available.
For producing a relocatable source it may be possible to rely on some custom emulation which would automatically anotate a simple disassembly. My point is that better tools are required if we want to make those quality C64 ports happen.
-
3
-
-
bollocks... looks like pretty much all asm entries on the 6502 platforms used OS calls 😝
-
1
-
-
22 hours ago, MrFish said:
I don't see why not. There's nothing saying you have to code for the entire series of a machine. Although you might get some flak from those who are...
The rules should have been more specific I think... memory/OS. I'm guessing using the OS will help too so perhaps there should have been more categories.
10 hours ago, carlsson said:Colour memory on the C64 defaults to the background colour so you need two POKEs or a quick flickering of background colour, clear screen and flick the background again. That overhead adds bytes and execution time. Unfortunately there is no native PRINT AT or PLOT method, and going through Kernel calls for printing at a given position adds even more overhead than the two POKEs.
Perhaps I should try to port my code to the C64 if I can find the motivation!
spoiler
Quote74 bytes with xex header no OS use, I'm feeling that it's not optimal but I've run out of ideas.
-
Also to people who posted sizes for asm versions, do you include the 6 bytes xex header ?
Do you use the OS ?
spoiler
Quote75 bytes including xex header but no screen clear and hardcoded screen addr
-
19 hours ago, Panther said:
The screen location depends on memory and other factors. Use SAVMSC ($58/$59).
ah right... not exactly fair since we have different models but the C64 doesn't so they can write directly to the screen I guess.
The minimum it adds is 4 bytes but then Altirra basic writes over it because the star is plotted on the 1st line. No issue with Atari basic.
Just wondering what the other folks using asm do ? hardcode the pointer or read SAVMSC ?
I'm thinking I'll just leave it hardcoded... it should work with any A8 with 64+KB with Altirra/Atari OS and Altirra/Atari basic
-
10 hours ago, TGB1718 said:
My assembler version has no cursor, no clear screen and no ready prompt, it's also quite tiny
You may be doing it wrong though 🙃
(saved a few more bytes)
-
Made my own asm attempt (hidden result)
Quote88 bytes including the 6 bytes xex header. I'm guessing we'll see entries below 80 bytes...
I'm assuming that the screen is always at $9c40, is that ok ?
I didn't clear the cursor either... it's kind of conflicting to allow a ready prompt but not the cursor and at the same time not require the screen to be cleared
QuoteDo I need to clear the screen?
No. Usually, you will paint / write on new, empty lines below the cursor. Just don't interfere with the OS messages, which are above the cursor, usually.
Can I write over system messages, or do I have to write starting below the cursor?
Well, you can write everywhere. Also, over the system messages. But your algorithm should not be based on the system message or require it. You could even delete the screen by hand before running your code.
edit: I guess it's ok to leave the cursor
-
14 hours ago, RafalDudek said:
real atari 65xe
Very nice, do you plan on adding colors for the main character ?
Thanks for the cheapshot... RMT2LZSS does exactly as the title says with a button click, and integrating it with the example source is just a matter of renaming the file and assembling the code
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Unicorns season: Prince of Persia for the A8!
in Atari 8-Bit Computers
Posted
Thanks, I have plenty of experience with various machines but never attempted ports before.
As for following techniques, I don't think I did... Though there's one thing I was told at my job: Always start from something that works... which I used to be very much against at first but turned out to be a saner method than starting from scratch... altough sometimes not by a big margin!
I developed all the tools I needed in order to make my life easier.
Haven't done much progress on that front... I've been doing much on work on a RMT based tracker (see "moving beyond RMT"). Hopefully we'll get more music coming to the A8 thanks to a slightly improved import process (and Tatqoo's efforts!)