LinkoVitch

IIRC with pointer maths (it's been a while ) but whilst a pointer is itself 32bit, an increment with ++ will increment the pointer by it's type size (assuming it's a typed pointer). So a Uint16_t* will increase by 2 bytes irrespective of if the pointer itself is 32 or 64bit. I *think* that's correct

unless you decide you want to insert something part way through or at the start of one of your switch statements.. at the moment you will have to update the values for all the subsequent case statements with new values. As that Switch statement grows, the amount of effort to make a small change near the start becomes more complex and time consuming, making it more faff to tinker and change things later.

Google is your friend. Simple google of "writing scalable code" gives a bunch of results. We are not making these terms up! 1st link: https://blog.sarasarya.com/what-the-hell-is-scalable-code-anyway-f6626ad78227 Scalability applies to more than just sprites. RE Switch.. Think about it, how does the computer know what part of the case statement to run? It doesn't magically know that a value of 15 = run this code.. it has to check each possible solution to figure out what bit of code to run. So a Switch statement with 100 possible cases will compare the input value with each in turn until it finds the one that matches and then run that.. So if you have 100 cases and the value you pass in doesn't match any of them, it will check against all 100 and then move on to the next instruction after the switch, so you just made 100 comparisons for nothing! From a cursory glance at your code I assume you are using a counter to indicate when something should happen? when it reaches a certain value, do a thing and you are using the switch statement to decide what thing to do, but you are doing this every iteration, so even at times when nothing should happen. I am sure there will be more efficient ways to trigger "events" and the like at set times, some things may happen on a timer, but I doubt everything should do. This is the designing part of the code, figure out how to do as little as possible each frame/tick/iteration, only trigger events when it makes sense, if something can only happen after a specific other event has happened, don't test for it every iteration, only after that event, or trigger it directly from that event. Programming isn't a simple subject there are many many many ways to do a thing (especially in games!) which is why it's so much fun, there is so much to learn and expand on, I've been coding for probably 30 years, I am still learning new things.

Your answer to 3 proves Welshworriers point 1. When code is said to not scale it means that the code is very rigid to a specific use case, if a small aspect of that case changes then the code has to be changed to accommodate that use case. Writing such rigid code and trying to make it fit, results in a tangled and complicated mess which ends up generally being the cause for bugs and is notoriously difficult to maintain and debug. Writing modular scalable code, you could re-use common logic for different purposes (say Menu input and gameplay input with a joypad), without having to modify loads of code or produce tangled spaghetti code. IE you could have something that reads pad input and presents it in a standard format. Then have an interchangeable handler function for each use case, which knows how to interpret the users key presses into actions. The game then references the appropriate handler for the appropriate part of the game. If you then decide to change how the gameplay inputs work, you only need to handle the GamePlayControllerHandler and don't make any changes to the InputCore or the UIControllerHandler. Using a modular and scalable solution also allows you to handle multiple input types, using adaptors and different handlers as required.

Might be worth adding a "If you bought this you have been ripped off, the disc is free here:" kind of thing to the start. Just noticed it's split into a bunch of parts and Nero.. if there are ways this could be made simpler for people to burn then may help too. Some people I imagine will want the box and label and simply won't be interested in burning themselves. Unless you are going to produce them on demand it's always going to happen.

JagCD units WILL fit into one another, I've had 3 or more plugged in like that on a shelf. Never tried it on a system as I didn't want to put excessive strain on the connector, and I didn't power up because I CBA finding enough PSUs to try I'd imagine it will work to a point, and then the bus will be extended sufficiently far enough with enough connectors that it will probably just become a huge noise generator / antenna and the Jag will just crash.

Don't see any reason why not assuming it is available as a Linux application? Do you have URL for it? Sorry for the slow response, I don't always get around to keeping up to date with the retro goodness these days

Sounds like you have sorted it? One thing to be aware of is if you stop a mod that has looping samples, these will continue to play after the mod processing stops, which is where sending stop commands or volume commands to voices 0-3 is needed too.

Why on earth would it require Visual Studio? If you had to have VS installed then you might as well compile them yourself and it negates the need to distribute binaries. You sure you don't mean it needs the MSVC runtime distributable? Plus you need to be specific as to which version 2015, 2017, 2019 etc they are not cross compatible.

Which then complicates the silicon as it now needs to handle phrase and qphrase alignments, means an extra address line too, just so you can save a few bytes of RAM? doesn't seem like a worthwhile trade of. I'm no silicon engineer, but I am pretty sure that things that seem trivial or simple in code are not going to be as simple or trivial to implement in silicon, added complexity I would imagine leads to greater chance of bugs in the hardware, more transistors needed etc, and if you are close to budget not everything is possible.

Yeah, *NIX OSes (with the exception of MacOS) are case sensitive. It's worth getting into and not being sloppy with such things. If you keep everything correctly cased, then no issues, worth a little faff to correct case on stuff you are working on, it's a one off thing that doesn't negatively affect anything.

I use it as part of my GIT servers CI/CD integration process. When I push up changes to my Sound Engine code, it automatically uses that container to test the project builds without errors and if successful generates a release zip file for me. I only released the container (which is like a small linux build with compiled versions of the tools) because I figured it may be handy for others as it was going on the Docker public repo anyway. If you run it, you will be dropped in at a command prompt from which you have access to make, rmac and rln. docker run -it hisol/jagbuild This won't be terribly useful unless you mount your local path containing your source into the container, then you can use those tools to build your source and get access to the result. so something like docker run -it -v /home/myuser/jagsource:/source hisol/jagbuild which would mount the local directory /home/myuser/jagsource into the container at /source, essentially allowing the container to see the files on your machine in that path, from which you could then run the tools cd /source make <magical make build stuff happens> That is pretty much it. There are plenty of help files etc on dockers website to explain the various switches etc, (you should really put --rm in that command after -it, or you will gradually end up with a full drive of old container volumes ) This should work under windows, but YMMV as Docker under Windows is mostly made of fail and crashes.

You have no idea if his reasons are good or not, he doesn't owe you anything. He is even leaving the repo up for a couple of days to allow people to make copies if they so wish, so he's not stopping you from doing anything. You are being very self centred. Hardly "taking his ball and going home", he has developed and provided support for this language for the last 6 years for FREE, and from what I have seen very little thanks! He is under no obligation to keep developing or supporting anything. If anyone could be accused of "taking their ball" etc, it would be you for this poor attitude.

Assuming I am understanding what you are doing (I think you might have pasted the wrong bug link BTW) I think the current version or RMAC does work correctly for calculating the difference between two labels. I have the following code in the SE .pc: move PC, JUMPTO addq #(mainloop - .pc), JUMPTO to calc a branch to the main loop, and that is working fine for me.

I'd have thought the CPLD would have been programmed via the JTAG and the voltage supplied by the programmer itself via the JTAG header? RE amps, it will draw what it needs, you just have to supply enough potential. IIRC the analogy is imagine the wire as a water pipe, Amps is the diameter of the pipe, voltage is the pressure, so as long as the "pressure" (volts) isn't too high the amps won't matter.

I would suggest one of the tips that is flat and angled (looks a bit like a knife point). The theory I read was that the tip is cooler at the point than the larger portion, so as you drag along the pins keeping the whole flat edge on the pins with the point end being the last to touch the pin as you pass over, the solder is slightly cooled and it distributes evenly. Obviously dab a LOAD of flux over the unsoldered pins with the part in place, makes a cool popping noise as you solder but helps with the bridges. My drag soldering is a bit naff tho

Yes the CLUT can only have 256 colours in it. Don't use an indexed bitmap object, use a 16bit or 32 bit object. The CLUT isn't used if the colour data is stored directly in the pixel data. Might be worth asking this question in the RB programming section, I have never used Raptor Basic

Your assumption is wrong, the Jag can display 24bit true colour images, 16/15bit RGB, 16 bit CRY, as well as 256x 16bit colours on screen at the same time.

I don't know why you are fixating on 16 colour TBH, that is just one of the options. Personally I'd go for 16bit 1st unless it was blatantly unnecessary, and scale back as issues arise. I'd not be surprised if the large static background on Rayman was 8bit, it has a fairly subdued colour scheme, possibly less than all 256 freeing up some of the palette for the text etc. I am speculating I've not tried pulling the ROM apart yet

From my own CoJag digging, ATari do like to use 8bit colours.. dunno why, CoJag has more memory, more ROM, more CPU and more bandwidth..

Think we are at cross purposes here and perhaps I haven't understood your meaning. 1) Yes obviously if you are taking a photo and want it to look like a photo, a horribly dithered mess isn't going to cut it. If you have an image that can be rendered using less than 256 distinct colours and look the part, then that should absolutely use indexed pixels. There maybe fewer colours, but they are still 16bit. 2) I am no artist :), so yes there are more ways to do things which won't mangle foreground sprites. Having a more subdued palette in the background works nicely for me (in games where I have seen it). If there is memory and bandwidth to spare, sure have a 16bit or a 32bit colour background.. but if the background isn't the key focus of the game, might be worth halving the memory/bandwidth footprint and squishing it into 256 or less. Won't always be possible. It's going to matter precisely on the project and the resources, there is no single right answer.

Nope, I think you should re-read what I put about the reasons for using indexed objects. You are absolutely correct you should use indexed object for those types of images, and I never said otherwise. Save on storage, bandwidth etc, much more efficient. I *DID* say that you *COULD* use those and the jag would be able to handle it, counter to what you put saying it could not. I don't recommend you do mind, but if done properly the Jag COULD do that.

I guess you refer to this Chris: And that "technique" was known way back in the days of them designing the silicon and publishing the developer manual. Technically EVERYONE has used that technique, because without it the OP crashes/acts weird, and probably pretty much everyone else with more than a handful of objects on the screen will have done it. This isn't some secret dark art that only the elite few know. I've actually mentioned it in passing a bunch of times in my posts on this thread in fact.

I'm going to chip in as there seems to be some confusion with what I said and stuff, so just to add in my 2p Fishing frenzy most certainly shouldn't tax the jag at all, punting sprites it can do. Of course a badly created object list will overly tax the system for what it is drawing on the screen, but even with a simple list with no branches I'd imagine the jag could happily handle fishing Frenzy. There seems to be some confusion about the "bit" of colours... Now, this is the confusion.. a 1bit, 2bit, 4bit and 8bit image on the jag are all using 16bit colour :).. the 1,2,4, & 8 refer to the size of the colour index into the CLUT (Colour Look-Up Table). Each entry in the CLUT is 16bit RGB or CRY depending on mode. The index value of a pixel simply points to which colour in that LUT to use. So a 1bit image can be 0 or 1, 2bit = 0-3, 4bit = 0-15, and 8bit = 0 - 255. The assets are high quality colour, just the pixel data is stored efficiently. Plus backgrounds should be somewhat duller and less detailed to avoid making foreground objects difficult to differentiate. Not for the graphics, but depending on the complexity you can spam the bus by making too many calls or tie the OP up with too long a list (the whole list is processed every single scan-line, every frame.) If you have a large image using indexed pixels saves a load of RAM and also memory bandwidth. The OP will like to read it's data in 64bit wide chunks. 1 64bit read is 4x 16bit pixels, 8x 8 bit pixels, 16x 4 bit pixels, 32x 2 bit pixels, and 64 1bit pixels.. so for Jeffs 352 pixel @ 4bit that's 22 reads to read a whole scan-line, vs 176 reads if it were 16bit. (assuming my dodgy mental maths worked there ). Of course if the object is smaller than a single read, you are going to waist a chunk of that potential pixel slurping. Whilst this may all sound super ossum, it does have it's own cost, in that an indexed Object has to also do a lookup in the CLUT to find the actual colour to paint, so there is additional overhead there, only slight, but still something to bear in mind. oh and you are limited to 256 colours in total shared between all those Indexed objects. Sorry Jeff, it won't.. not if it's done correctly. When you move something on the screen with the OP, it doesn't actually "move" anything. If you badly build your list, don't make use of branches and a well structured list, or have overly large objects that hang off the sides of the screen, then yeah it's going to struggle and fail. But it is entirely possible to have a full screen image with many layers of parallax. Sorry if that's a bit all over the place HTH anyway

I quite liked planar but then we established years ago I'm not normal