VladR

Yeah, I know it would be nice. Remember when I was posting videos and rebooters were bitching that I was doing it "just for attention "? Now it's been more than a year without a vid (I guess, haven't checked the timestamp of last one, but I haven't made one this year, and it's almost end of October), so does it look like I am doing this for attention ? Either way, you know who to thank for no videos

Nice try, you just "missed it by thaaaaaaaaat much" While my first game will have a StunRunner-style (visually) tracks, the second one will use the engine I developed for the minigame, so I will be able to use generic meshes at any spot in the 3D world, as the track contains pointers to the meshes, hence the visuals can be much more advanced, varied and rich. Someone will have to model all those bridges, tunnels, buildings and other objects. Which is exactly where this tool comes in handy, so in parallel, while I'm busy with finishing first game and its missing components, some external artist can start working on the gfx of second game, so by the time carts start being produced (hopefully March next year), the gfx for second game will be ready, hence it shouldn't take me more than ~3 months to finish the second game as I will only have to adjust physics, gameplay, music and some engine-related tweaks, with 75% of existing codebase remaining unchanged. But, I get it - the forward-thinking is a very abstract concept, so -really- don't feel bad if you don't fully comprehend it Yeah, like I said, it's more of a long-term achievement, than anything that substantially speeds up finishing my first game (I won't use external artists for my first game). Though, it will help me populate the hangars (in between levels) much faster, that's for sure. It is a major paradigm shift in the whole process, so I figured it was worth mentioning here. All sarcasm aside, if you're so tired of my sh*t, why don't you just put me on ignore ? Problem solved. Hmmm ? Or would you rather I put you on a list of people whose replies I always ignore ? Either one is fine with me, as if your only contributions is bitching, I can actually do just fine without reacting to it. You have 48 hours to think on it (after that, assuming I don't hear back from you, Option No 2 will be used by default). Just remember that each of those poor souls, every time they take a sh*t in this thread, it always brings a cheerful smile to my face, but as I actually respect your coding skills, please don't voluntarily continuously humiliate yourself like that. I will, however, fully respect your decision...

Fair enough

Thanks for the stats, it's quite different seeing it like that, compared to just browsing it (year by year) on their site. Would you happen to know how is WILD category scored ? I was checking the results page https://gkanold.wixsite.com/homeputerium/kopie-von-results-2019 However, there are no scores there for those. Perhaps the scores are only internal for WILD ? Seeing Amiga there made me realize why not submit something for Jaguar into the WILD...

If Flashback is for 2600, then it obviously cannot have a built-in one, as it's not a computer like Atari 800. But, you just mentioned XEGS and 7800. I totally have not considered those, yet because they're not computers, they, by default, require compiled code Did anybody submit anything for those, ever ? I checked last 2 years of entries, and nothing. Then again, it's not an 8-bit computer, so perhaps that's the reason nobody tried.

Did you schedule at least some sleep ? Metal Studded winter tires are a major legal problem. Plenty states outlaw them with very strict timeframes when they are allowed and they could easily impound your car plus give you hefty fine. The only way you can drive them hassle-free is to be ready to keep changing the tires on a weekly basis, based on current weather. It's plain ridiculous. Haven't checked North Dakota yet, so perhaps they're useable here for the whole season, regardless of current weather, but I would not dare to drive them during winter across U.S. Back in Europe, I also used to change between winter and summer tires, but here in U.S., the all-season ones are a "good enough" compromise for both summer and winter. Few years ago, I drove for 8 hours straight through a major winter storm in Newfoundland from one edge of the island to another. Never saw that many cars in a ditch in one day, but my all-season tires gave me just enough traction (even without 4x4). Current forecast for my spot is 3 feet (almost a meter) of snow till Saturday. Undeniably, it's first week of October, though I'm not complaining, as at least this year the first winter storm was delayed

I'm going to be setting up my table on Friday (highly likely afternoon). When are you arriving ? I'd love to go out on Friday - I suspect I'll be beat on Saturday Though, truth be told, it's hard to precisely estimate my arrival, as it's a 2,600 km drive and there's a fresh snow coming in 2 days covering about 2,000 km of the drive and not much will melt by the time I depart (with a current 30% likelihood of another storm exactly around my departure). Since I survived 2 winters in Montana without winter tires, driving through blizzards, white-outs and ditches, I'm not going to change that habit now Maybe I should target arriving Thursday night, I'll keep an eye on weather forecast...

Well, TGI offers all the sprite (and other) functionality that I don't currently have implemented in my engine, as I am not using sprites in my flatshader. Another advantage is, that it's already in my dev environment. Besides, nothing stops me from having a TGI-based distribution and a separate non-TGI-based distribution (using my own or other people's libraries). I could, for the time being, offer a SW-rasterizer codepath (via some new command : SpriteEngine (SW)) and eventually, once I get around to implementing it, supply Suzy-based codepath (via HW flag). I don't believe it should take me more than couple days, anyway, to debug how to use sprites and scaling via Suzy. I, for sure, wouldn't want to have to call other EXE tools (the sprite exe files that are used currently to convert the sprites) that might later down the road break the whole thing because of some unforeseen dependency. For jaguar, I was doing all sprite import, conversion and palette work using custom-written .NET code, hence I was able to supply nice error messages if something went wrong, right during the translation process. Of course, since all this is just remapping between the BASIC and C, supplying a different version of a sprite library should be as easy as replacing a *.h or *.c file of the specific implementation. From what I could see so far, cc65 does a pretty good job of not linking a function unless it's explicitly called, so it won't matter if the library has hundred functions, it won't affect the executable size.

About 6 years ago, for a Jaguar, a created a VRBasic Translator (in .NET) that translates VRBasic code into C and then feeds it into the C compiler to get the target platform (Jaguar) binary. Since, allegedly, there's no BASIC for Lynx (I really wouldn't know, as I'm ignorant on the platform's history and only got familiar with coding it in C/Asm few months ago) - it looks like it might be worthwhile to port the VRBasic to Lynx as that might entice more users to the platform. I took the liberty to implement the Microsoft's syntax of BASIC, so this would be unfortunately quite far from the Atari 800 XL's Basic syntax (with line numbers), but: - it's still much more accessible than C - no Line numbers - no curly braces - no semicolons - you can use hardcoded paths to your art assets (sprites) right in your code (without using any external tools), and the backend will do all the heavy lifting (loading, conversion, alpha keying) at the compile-time, so on Jaguar it just works Here's one sample to show the syntax: ' VRBasic Sample 05 - Sprite Drawing ' Sep-2013 ' Declare the sprite variable as a global variable to avoid passing it to every function using it Module Globals Dim ImgWall As Sprite End Module ' Draw all colors in the palette Sub DrawPaletteAt (xp As Integer, yp As Integer) For idxColor As Integer = 0 To 255 DrawPixel (xp + idxColor, yp, idxColor) Next idxColor ' Draw some helper points every 32 pixels to assist with picking the color index For idxHelper As Integer = 0 To 8 DrawPixel (xp + idxHelper*32, yp+1, 127) Next idxHelper End Sub Sub Main () SetGraphicsMode () DrawPaletteAt (32,0) ' LoadImage takes a full path, so you will have to update it based on where you installed the VRBasic LoadImage (ImgWall,"c:\jaguar\_Projects\_VRBasic\src\Samples\ArtAssets\TileA2_16_Colors_Palette.gif",8) ' Now let's place the palette of the loaded image at the desired destination in our palette - for example at index 100 CopyPalette (100,ImgWall) ' Of course, since we changed the palette indices of the image after loading, we need to update the image data for the same offset ' Under Virtual Jaguar, upon every restart of the *.j64 (e.g. when it reaches End Sub for Main () ), this will have the effect of further offseting the colors, since VJ does not seem to reload the *.j64 (merely jump to Sub Main), thus the Image Data are not physically reloaded OffsetImage (100,ImgWall) ' Let's display the sprite roughly in the middle of the screen ShowImage (ImgWall, 160,100) Wait (5000) End Sub Obviously, the platform's specific functionality (sprites, palettes, etc.) would have to be recoded for Lynx (or use TGI), but the basic language should, in theory, compile fine (assuming no major differences between jaguar's C and cc65) right out of the box. I should also have a full PDF documentation, somewhere on my hard drive...

Philsan alerted me to this thread in my 2020 10-Liners thread (in the 8-bit section). I wasn't aware there was no BASIC for Lynx, that's crazy!!! It made me realize that about 6 years ago I wrote a VRBasic translator (BASIC -> C) that then feeds into the jaguar's C compiler. Since we have the cc65 on Lynx, 95% of work has already been done by me and there hopefully shouldn't be too many issues with the cc65/6502 idiosyncrasies (compared to jag's C compiler). It does, however, use Microsoft syntax, so not sure how well that would be received. Here's one of the samples to show the syntax: ' VRBasic Sample 06 - Screen Drawing ' Sep-2013 Module Globals Dim lvlData() As Byte Dim ImgWall As Sprite End Module ' Draws a specific screen from the loaded map Sub DrawScreen (ScrCol As Byte, ScrRow As Byte) Dim xpos As Integer = 0 Dim ypos As Integer = 0 Dim idx As Integer ' idxOffset is an offset to get to next row in the map. It should be 8* (ScreensPerMapRow-1), e.g. 8 * (2-1) = 8 in our case Dim idxOffset As Integer = 8 ' This is our global index into the map array idx = (ScrRow*(3*8)*2) + (ScrCol*8) ' Render 3 Rows For row = 0 To 3 ' Render Row of 8 Sprites per column For col = 0 To 8 ' Check for 'X' (ASCII:88) and draw the sprite If (lvlData(idx)=88) Then ShowImage (ImgWall,xpos,ypos) Else ShowBlankImage (ImgWall,xpos,ypos) End If ' Irrespective of the 'X' we move right in the increments of Sprite Width xpos = xpos + ImgWall.xl idx = idx + 1 Next ' Update the xpos,ypos for the next row of sprites xpos = 0 ypos = ypos + ImgWall.yl ' Move the index into map data at next row idx = idx + idxOffset Next End Sub Sub Main () SetGraphicsMode () ' This is our level data in a text format. Each screen is 3 rows by 8 columns, whole level has 2 rows of screens, each row having also 2 screens ' Base advantage of this format is that one can edit whole map in a Notepad LoadTextData (lvlData, "c:\jaguar\_Projects\_VRBasic\src\Samples\ArtAssets\level00.txt") ' This is our Wall Sprite LoadImage (ImgWall,"c:\jaguar\_Projects\_VRBasic\src\Samples\ArtAssets\TileA2_16_Colors_Palette.gif",8) ' Push the palette colors at index 1 (for example) CopyPalette (1,ImgWall) ' Update the Image data OffsetImage (1,ImgWall) ' Render all screens, one after another For ScrRow = 0 To 2 For ScrCol = 0 To 2 DrawScreen (ScrCol,ScrRow) Next Next Wait (5000) End Sub Of course, the execution speed depends on C compiler, in our case, it would be cc65. But, from coder's standpoint - it's a BASIC, not a C (though, as much as I tried to provide human-readable error messages for common syntax errors, you would still get the C-style compiler messages for the unforeseen scenarios) I should probably create a separate thread for this, I'll go do that now.

I wasn't aware Lynx doesn't have BASIC, as I merely looked into the platform for first time few months ago (because of the 30-year anniversary compo), noticed it had a CC65 compiler, which was all I needed so it was good. It strikes me absolutely shocking that there is no BASIC ! That's crazy! You know what, few years ago, for a Jaguar, I created a PC-based BASIC translator (called VRBasic) that translates BASIC into C and then feeds it straight into the C compiler toolchain (to get the Jaguar binary). Since we have a C compiler on Lynx, I could literally do the exact same thing. There might be some cosmetic changes, to allow for the syntax of CC65 or other 6502 idiosyncrasies, but in theory, 95% of work (parsing+translation) was already done by me. I was, however, at the time, very keen on "Modern BASIC", so I went with the Microsoft's syntax. Not sure how well would that be received... Here's one of the VRBasic samples showing the syntax: ' VRBasic Sample 06 - Screen Drawing ' Sep-2013 Module Globals Dim lvlData() As Byte Dim ImgWall As Sprite End Module ' Draws a specific screen from the loaded map Sub DrawScreen (ScrCol As Byte, ScrRow As Byte) Dim xpos As Integer = 0 Dim ypos As Integer = 0 Dim idx As Integer ' idxOffset is an offset to get to next row in the map. It should be 8* (ScreensPerMapRow-1), e.g. 8 * (2-1) = 8 in our case Dim idxOffset As Integer = 8 ' This is our global index into the map array idx = (ScrRow*(3*8)*2) + (ScrCol*8) ' Render 3 Rows For row = 0 To 3 ' Render Row of 8 Sprites per column For col = 0 To 8 ' Check for 'X' (ASCII:88) and draw the sprite If (lvlData(idx)=88) Then ShowImage (ImgWall,xpos,ypos) Else ShowBlankImage (ImgWall,xpos,ypos) End If ' Irrespective of the 'X' we move right in the increments of Sprite Width xpos = xpos + ImgWall.xl idx = idx + 1 Next ' Update the xpos,ypos for the next row of sprites xpos = 0 ypos = ypos + ImgWall.yl ' Move the index into map data at next row idx = idx + idxOffset Next End Sub Sub Main () SetGraphicsMode () ' This is our level data in a text format. Each screen is 3 rows by 8 columns, whole level has 2 rows of screens, each row having also 2 screens ' Base advantage of this format is that one can edit whole map in a Notepad LoadTextData (lvlData, "c:\jaguar\_Projects\_VRBasic\src\Samples\ArtAssets\level00.txt") ' This is our Wall Sprite LoadImage (ImgWall,"c:\jaguar\_Projects\_VRBasic\src\Samples\ArtAssets\TileA2_16_Colors_Palette.gif",8) ' Push the palette colors at index 1 (for example) CopyPalette (1,ImgWall) ' Update the Image data OffsetImage (1,ImgWall) ' Render all screens, one after another For ScrRow = 0 To 2 For ScrCol = 0 To 2 DrawScreen (ScrCol,ScrRow) Next Next Wait (5000) End Sub Obviously, the execution speed of that code is directly dependant on the quality of the C compiler, but I definitely noticed that cc65 produces much faster code than the jaguar's C compiler. Also, once you examine the cc65 output, it's entirely possible to write a CC65-efficient C code that will translate to almost perfect ASM (which is entirely impossible on jaguar as any C code there is just awful in ASM).

Well, that's probably because it's Amstrad and not Atari, so it's less known. Besides, the last thing I'd want to do is try to "sneak in" and hope to not go noticed. Way too much work for this. Especially given the fact that the category was there, just removed after a first year of no entries. I haven't checked - but how much time was there the first year between the announcement of FREI category and deadline ? Also 2 months ? Good luck doing something in that timeframe for first time... Isn't Flashback the 2600 platform ? I don't know from the top of my head. But perhaps that particular basic only allows compilation, so it's de-facto standard behavior ? Well, the WILD category is supposed to be for everything else clumped together (programs, demos, intros, etc.), but most importantly it violates the core purpose of the competition - the 10 Lines - as the wild category allows for programs longer than 10 lines, so one might as well supply the 64 KB executable, which defeats the whole purpose in the first place...

Interesting, You just gave me an idea: - I can embed a following scripted functionality into each executable: - show GR.0 with cursor - show command LIST that will display the BASIC program on screen (then wait 5 seconds) - show command RUN that will execute the pre-compiled BASIC program (then wait 5 seconds) The above is, like, 0.1% of the effort of creating a full-blown editor and a compiler, however it will create the "feeling" of the platform's BASIC, for the purposes of the competition.

Do I read that correctly that you have to physically be present at the employment office every few weeks ? That's, like, 1990-style. I'm really sorry to hear that that's the system in Portugal I was counting on the fact that you would receive the unemployment benefits to your account, so after 6 months you would have at least 2,000 EUR saved, which could provide some boost with other opportunities. But, that's not happening now... What's the immigration situation like between Portugal and U.S. ? Can you guys stay in U.S. for 6 months ? As for your personal stuff, couldn't one of your friends just store it inside their garage/basement in the meantime ? That shouldn't be too much to ask from them, I'd presume. I also,just now, realized that if you were here, you could perhaps learn 3dsMax (or maybe you know how to use it?) and eventually maybe work with me on my 3D games for Jaguar and Lynx. I could give you that Catch-22 first game experience (that you can't get without first working on a published game and vice versa) that every single game studio requires and from there you could work your way up, continue working on your art portfolio and keep submitting resumes to job/advertisement/visualisation agencies till you get lucky (but without the stress of survival). EDIT: Just realized, we wouldn't even have to wait for me till I am done with the missing components (mostly audio) to my Jaguar stuff. I already forgot, as it's been probably over 15 years now, but I have two published games on PC. Meaning, we could reskin them by using your 3D art assets, and just self-publish (using payment processors) it online (or try to put it up onto the shovelware of Steam), as I still have the full source code to both of them. What do you think ? Hypothetically, that could also work remotely (though, at much higher time/effort cost).

I would like to serve this topic as a discussion on the BASIC Ten-Liners Contest, especially the two areas: 1. Removal of the FREI category this year, which I believe is unreasonable and doesn't help the contest in any way. - Because the FREI category was established the previous year, this year I have been experimenting a lot with what kind of functionality I can fit into 10 lines of hexa code (about 2.2 KB of assembler code) - I just checked my source code, and I wrote over 5,000 lines (yes, five thousand) of assembler code, figuring out the best compromise between performance&size of the code for each component of the game - It was very exciting finding out what kind of functionality (some quite surprising and unexpected) can be fit within that limit - Hence, it was quite frustrating to see the category removed - For as long as there have been magazines with BASIC listings, inlined ASM code was always integral part of the charm of BASIC - since it doesn't in any way affect the other categories, I really see no reason why it should be removed - the only thing the removal achieved was two less entries for 2019 from me (and who knows how many other people were in same situation) TLDR: It can open up a new uncharted territory of games possible in 10 lines. 2. Inclusion of Compilers (as a separate category) - if my understanding of rules is correct, the only BASICs allowed are the ones that have an editor on the target platform (e.g. you must be able to type the program on an actual Atari (or other computer)) - this would rule out the compilers that exist on PC only - because of my recent work on Lynx, 2 weeks ago I have created a PC-based 6502 compiler (by modifying my Jaguar's 68000 & GPU RISC compiler) of a high-level language that resembles C, and feeds into the cc65 linker toolchain - it would be relatively easy to change the syntax of the language to be BASIC-like - there would be no Atari-based editor or compiler, as I really see no point in creating yet-another editor. - this can however bring the increased productivity of PC-based workflow (Notepad++, Photoshop, etc.) and increase the quality of the target application that is otherwise utterly impossible to achieve by purely typing program on a physical HW TLDR: It can further push the boundary of 10-liners due to much higher execution speeds of compiled code and increased work productivity on PC. It's important we know about this by the end of November, ideally. Posting a contest announcement thread on January 31 will be definitely too late for me (as I will be busy with Jaguar in Q1, especially around March) and I'm sure others would love to know too, as for us there are only 2 options: - resume/start the ASM coding for the 10-Liners Contest - ignore the Contest altogether

Jose, would you be willing to live in North Dakota for, say, 6 months ? I could pay for your return plane ticket (LIS -> ORD), pick you up at Chicago airport and drive you home, where you could stay at the top floor of my house (there's 3 unused rooms). You thus wouldn't have to worry about accommodation or food. Obviously, I wouldn't ask any money. Climate-wise, it's colder than Portugal, but we actually don't really get air below -40 'C, so it's not that cold either (except for the windchill, which does unfortunately, every now and then, cross into the -60 territory, but if you don't go out those days, it doesn't matter). Change of scenery might, however, tremendously help your heart and beat the inevitable depression (which can be a very nasty bitch, from a painful personal experience) and you would get better. And, I got the Ataris here - U1MB, Falcon, Jaguar, soon also Lynx...

I finally have a PC-based loader for the 3D meshes without having to export the mesh to *.OBJ, use my exporter, recompile the code and then load it up via Skunk - I reused my Atari:Dev.Emu codebase that I use for rapid prototyping for various platforms (A800, Lynx, Jaguar) - The PC rasterizer is using the exact same code that my GPU rasterizer on jag - It's been more than a year that I used it last time, and thought I won't anymore, but am glad I went through the effort of emulating jag's 68000 and GPU in my PC codebase - now I can finally see, real-time, while modeling in 3dsmax, an output how the mesh looks in target resolution and using same 3D transformations as on jag - the moment the mesh is exported from 3dsmax (takes 3 seconds (3 keystrokes)), the PC loader automatically reloads the file (without any intervention from user) - I burnt a week on this, so I am unfortunately not going to have as many different art assets for the PRGE demo (as I planned 2 weeks ago), but that's alright as the long-term advantage of this is tremendous This has increased the 3D modeling productivity by almost an order of magnitude, since I don't have to keep going back and fix issues in 3dsmax after checking the output on jag. I can now do more in an hour than I previously did in a day, so it's going to be very helpful for the next games that will be more art-heavy. Most importantly, I can now finally hire remotely any 3D artist, as he doesn't have to have a jaguar anymore, since he can just use the loader to verify the output instantly. So, with just a little bit of additional organizational overhead (emailing/Skype/milestones), while I'm finishing remaining missing components for my first game (audio, PAL, RPG stats, 3D art), in parallel, I can have art assets created for the second game.

For now, it is. To be willing to put it on cart, I must have a different audio driver(4-5 days) , fix the failed import of 3D assets and spend at least another 4-5 days on gameplay. That's around 15 days of work. Not happening for PRGE for sure I did, however, spent about 5 days on my inlined C-style language 6502 compiler and while short-term there's no benefit, long-term it's going to be more productive for Lynx. Assuming I create enough 3D art assets for my jag game, I may be able to to find 3 days to at least have nicer 3D meshes in the Lynx build for PRGE. Chance of that happening is about 50% now.

Virtue ? How would you know if you don't have the experience ? So funny. The arguments of hardcore console players haven't changed in ~quarter century - it's 1996 all over again Undeniably, there's a reason why Sony marketing worked so well. I have played both on the bleeding edge, constantly upgraded PC and PS1 at the same time. Have you at that time ? If not, then you don't know what I'm talking about.

I'm sorry, did I ever accidentally portrait myself as a console player ? Only select few things could insult me deeper than being thrown into that category. I've had years where I upgraded whole PC three times (within 12 months). So, what you're saying is that just because it was 'popular' and sold millions of units, it must have been 'cute' ? For console players, sure, as they didn't know any better. And those that did, kept denying, of course When Crash Bandicoot was released - ~1997, I bought a 3DFX card to my PC. That was one of the very few transformative experiences in PC gaming history - basically pre-3DFX era and post-3DFX era. I played Crash around the time of release, on a friend's imported PS1. Even at that time, it was extremely pixelated and low-res. There was a fun factor, sure, but it was undoubtedly pixelated & ugly, as 3DFX was actual next-gen and to me rendered whole PS1 library visually disturbing and unplayable without larger quantities of alcohol. But then, if we're talking about gaming while impaired, networking PCs and playing multiplayer when drunk in dorm was waaay more fun than PS1. Of course, if you haven't been exposed to a hi-end PC rig, you might have considered Crash 'cute', and that's fine. Good for you that you enjoyed last-gen as current-gen instead of next-gen. The power of marketing - but hey - "it was cheaper and you didn't have to configure anything", just insert disc&play, right About a year later, in 1998 I played Unreal 1 and NFS3 on PC with 3DFX. Contrast that to Crash on PS1, which not only looked pixelated&ugly, but comparatively was upgraded to ridiculous, as you're stuck with same unupgradeable HW forever. It's like comparing Atari 2600 vs Jaguar, visually. But, hey - there's still gameplay The good old times when those bloody consoles didn't pollute the PC gaming. It was an incredible fun while it lasted...

Incorrect. You're confusing 'cute 3D' with 'detailed 3D relative to the HW's capabilities'. There's no 'cute' looking 3D game on Lynx, or Jaguar and I'd argue not even in the massive catalog of PS1 (though many have tried). You start getting some of the 'cute 3D' factor around PS2-era, but the resolution and polycount really had to be bumped up to 1280x720, to be safe - e.g. PS3/X360 era, which finally allowed complex curved 3D meshes that were, indeed, cute. In contrast, in 2D pixel art, you don't need high resolution and high polycount for bitmap to be cute. Lynx's resolution and color depth is just fine for that.

Exactly. To give 'personality' via use of polygons, one needs insane amount of them, way above the HW's capability. However, flatshading allows me to do both code and gfx easily, as there's just few polygons. But, the polygons will never be cute. For that, you need GeForce-level HW power and resolution at least 800x600, from my experience.

But I'm not doing that - You're the only one here who tries to match my engine with the best ones. I'm perfectly happy with the performance in its current stage, given the fact that few weeks before that I didn't have any code running on Lynx Do you understand what it means when I said it's a "SW rasterizer" and that I don't use any power of the 16 MHz "Blitter" (Suzy) ? Not even to clear screen ? It's basically, like, Atari XL (160x96), just at 4 MHz instead of 1.79. Hence, there is a lot of upwards potential, once I start using the 16 MHz chip. Except Lynx's Suzy has a built-in capability to scale textured bitmaps, which is exactly what is needed for textured roads. Now, I haven't experimented with that yet, but karri has done exactly that scenario (road rendering) and he knows how fast that is. I believe he also mentioned in some thread that due to some glitches, he had to render the road (it was either road or that road edge polygon - don't recall exactly this moment) in two passes, which will be expensive, but should be still less expensive than a per-scanline-traversal, as a lot of CPU time is killed on that. I would definitely defer to his experience here. Regardless, my plan for OutRun is to use Suzy to render textured scanlines (yes, not whole scaled road segment polygons), because this will achieve the full perspective effect on the environment texture (e.g. most distant grass scanline will look different than nearest one - helping the perspective, especially in fast motion). If that turns out to be too slow, then I can always go back to the scaled road polygon method (and scaling the grass texture as another polygon, instead of per-scanline basis, though loosing the per-scanline XP offset, which is part of the full perspective). But, it's definitely a method worth trying out, IMHO.

Wow, so you cannot imagine polygonal road with outrun's land texturing and sprites? How's that for ironic ?

Oh yeah, I know. There's at least dozen gentle-soul humanoids shaking in anticipation of the opportunity to tear it to pieces on YT the moment it goes public But, like I said million times, I can release my first Jaguar game only once in my life, so I take my time with it. My second Jag game has the current dev estimate sitting at around 10 weeks.